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1 METHOD AND SYSTEM FOR ROUTE CALCUATION 

2 IN A NAVIGATION APPLICATION 

3 

4 BACKGROUND OF THE INVENTION 

5 The present invention relates to a system and method for route calculation in a 

6 navigation application program. 

7 Computer-based navigation systems are able to provide end-users, such as 

8 vehicle drivers and as well as others, with various navigating functions and features. 

9 For example, some navigation systems are able to determine an optimum route to 

10 travel by roads between locations in a geographic region. Using input from the end- 

1 1 user, and optionally from equipment that can determine the end-user's physical 

12 location (such as a GPS system), a navigation system can examine various routes 

13 between two locations to determine an optimum route to travel from a starting 

14 location to a destination location in the geographic region. The navigation system may 

15 then provide the end-user with information about the optimum route in the form of 

16 instructions that identify the maneuvers required to be taken by the end-user to travel 

17 from the starting location to the destination location. The navigation system may be 

18 located in an automobile and the instructions may take the form of audio instructions 

19 that are provided as the end-user is driving the route. Some navigation systems are 

20 able to show detailed maps on computer displays that outline routes to destinations, 

2 1 the types of maneuvers to be taken at various locations along the routes, locations of 

22 certain types of features, and so on. 

23 In order to provide these and other navigating functions, present navigation 

24 systems include navigation application software programs and use one or more detailed 

25 databases that include data which represent physical features in geographic regions. 

26 The detailed database(s) includes data which represent the road network in a region, 

27 including the roads and intersections in the region and information about the roads and 

28 intersections, such as turn restrictions at intersections, speed limits along the roads, 

29 street names of the various roads, address ranges along the various roads, and so on. 

30 Further, the data may include information about points-of-interest. Presently, the 
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1 collection of such geographic data and the provision of such data in a computer-usable 

2 database format are provided by Navigation Technologies of Rosemont, Illinois. 

3 Present navigation application programs and navigation systems are able to 

4 provide many advantages and many useful features. However, there continues to be a 

5 need for improvement. One area in which there is need for improvement relates to 

6 providing the end-user with better and more detailed navigation instructions at an 

7 initial stage of a route. Another area in which there is need for improvement relates to 

8 providing the end-user with better instructions as the desired destination is approached. 

9 Still another area in which navigation systems can be improved relates to providing the 

10 end-user with better instructions as to how to get back on a route to a desired 

1 1 destination when the end-user either accidentally or deliberately deviates from a 

12 previously calculated route. Still another area in which there is a need for 

13 improvement relates to handling of intermediate stops along a route. For example, an 

14 end-user will often want to make one or more intermediate stops between a starting 

15 location and a final destination. Thus, there is a need for a navigation system 

16 application that can not only calculate a route between two locations, but also that can 

17 calculate quickly and effectively a route that includes stops at one or more intermediate 

18 locations along the way between a starting location and a destination. A further area in 

19 which there is need for improvement relates to provision of a universal route 

20 calculation module or tool that can be readily used in a variety of different software 

21 and hardware environments without the need for extensive revisions and 

22 customizations to the tool. 

23 Accordingly, it is an objective to provide a navigation application that provides 

24 improved route calculation features to an end-user. 

25 

26 SUMMARY OF THE INVENTION 

27 To address the above concerns, according to one aspect of the present 

28 invention, there is provided a program and method for a route calculation tool for use 

29 with a navigation system and used with a map database. The route calculation tool is 

30 adapted to find at least one solution route between a first location on a road network in 

3 1 a geographic region and a second location on the road network in the geographic 

32 region. The route calculation tool includes a first search tree associated with the first 

33 location and a second search tree associated with the second location. Each of the 
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1 search trees is adapted to hold gates. Each of the gates represents a physical position 

2 on the road network and a direction from the position to another location along a path 

3 on the represented road network. The route calculation tool also includes a priority 

4 queue associated with each of the search trees. Starting with one of the search trees, 

5 the priority queue assigns a priority to each of the gates based upon an evaluation by a 

6 search algorithm. A search engine expands the gate that has the highest priority to 

7 determine one or more successor gates thereof and compares the one or more 

8 successor gates so formed to one or more gates in the other search tree. The process 

9 of growing either or both search trees by expanding the gate that has the highest 

10 priority in its respective search tree is continued until a gate in the search tree 

1 1 corresponds to at least one of the one or more gates in the other search tree. 
12 

1 3 BRIEF DESCRIPTION OF THE DRAWINGS 

14 Figure 1 is a block diagram of an exemplary navigation system. 

15 Figure 2 is a map illustrating physical geographic features in a portion of a 

16 geographic region represented by the geographic database in Figure 1. 

17 Figure 3 is a block diagram illustrating the organization of the geographic 

18 database in Figure 1 . 

19 Figure 4 is a block diagram showing components of the navigation application 

20 of Figure 1. 

21 Figure 5 is a diagram illustrating the components of the configuration object of 

22 Figure 4. 

23 Figure 6 is a diagram illustrating the components of the vehicle object of Figure 

24 4. 

25 Figure 7 is a diagram illustrating the components of the output route object of 

26 Figure 4. 

27 Figure 8 is a diagram illustrating the components of the time object of Figure 4. 

28 Figure 9 is a diagram illustrating the components of the navigation position 

29 object of Figure 4. 

30 Figure 10 is a diagram illustrating the components of the locus structure of 

31 Figure 9. 

32 Figure 1 1 is a diagram illustrating the components of the waypoint object of 

33 Figure 4. 
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1 Figure 12 is a diagram illustrating the geographic features represented by the 

2 waypoint object of Figure 1 1. 

3 Figure 13 is a diagram of the components in the route calculation object of 

4 Figure 4 in one stage of operation. 

5 Figure 14 is a diagram of the components in the route calculation object of 

6 Figure 4 in another stage of operation. 

7 Figure 15 is a diagram of the components in the route calculation object of 

8 Figure 4 in yet another stage of operation. 

9 Figure 16 is a diagram illustrating the components of the waypoint structure 

10 which is stored in the route object of Figure 7. 

1 1 Figure 17 is a diagram illustrating the components of the gate data structure of 

12 Figures 13-15. 

13 Figure 18 is a diagram illustrating the components of the gate data structure of 

14 Figures 17 when used as a seed gate. 

15 Figure 19 is a diagram illustrating the list of solution routes in Figure 15. 

16 Figure 20 is a diagram illustrating the components of the waypoint data 

17 structure which is used in route calculation object of Figures 13-15. 

IS Figure 21 is a map illustrating the concepts associated with a rank suppression 

19 feature according to one alternative embodiment of the route calculation program. 
20 

2 1 DETAILED DESCRIPTION OF THE 

22 PRESENTLY PREFERRED EMBODIMENTS 

23 I. NAVIGATION SYSTEM OVERVIEW 

24 Referring to Figure 1, there is a block diagram of a navigation system 10. The 

25 navigation system 10 is installed in a vehicle 1 1, such as a car or truck, although in 

26 alternative embodiments, the navigation system 10 may be located outside of a vehicle 

27 or may be implemented in various other platforms. For example, the navigation system 

28 may be implemented as a hand-held portable system, or may be implemented on a 

29 personal computer (such as a desktop or portable notebook) or a personal digital 

30 assistant. The navigation system may also be implemented in a networked environment 

3 1 or on a client-server platform. 

32 Referring to the embodiment illustrated in Figure I, the navigation system 10 is 

33 a combination of hardware and software components. In one embodiment, the 



- 4 - 



1 navigation system 10 includes a processor 12, a drive 14 connected to the processor 

2 12, and a non-volatile memory storage device 16 for storing a navigation software 

3 program 18, as well as other information, such as configuration parameters 19. The 

4 processor 12 may be of any type used in navigation systems, such as 32-bit 

5 processors using a flat address space, such as a Hitachi SHI, an Intel 80386, an 

6 Intel 960, a Motorola 68020 (or other processors having similar or greater 

7 addressing spafce). Processor types other than these, as well as processors that may 

8 be developed in the future, are also suitable. 

9 The navigation system 10 may also include a positioning system 24. The 

10 positioning system 24 may utilize GPS-type technology, a dead reckoning-type 

11 system, or combinations of these, or other systems, all of which are known in the 

12 art. The positioning system 24 may include suitable sensing devices 25 that 

13 measure the speed, direction, and so on, of the vehicle. The positioning system 24 

14 may also include appropriate wireless communication technology to obtain a GPS 

15 signal, in a manner which is known in the art. The positioning system 24 outputs a 

16 signal 26 to the processor 12. The signal 26 may be used by the navigation 

17 software program 18 that is run on the processor 12 to determine the location, 

18 direction, speed, etc., of the navigation system 10. 

19 The navigation system 10 also includes a user interface 31. The user 

20 interface 31 includes appropriate equipment that allows the end-user to input 

21 information into the navigation system. This input information may include a 

22 request to use the navigation features of the navigation system. For example, the 

23 input information-may include a request for a route to a desired destination. The 

24 input information may also include other kinds of information, such as configuration 

25 information or vehicle information, as explained further below. The equipment 

26 used to input information into the navigation system may include a keypad, a 

27 keyboard, a microphone, etc., as well as appropriate software, such as a voice 

28 recognition program. The user interface 31 also includes suitable equipment that 

29 provides information back to the end-user. This equipment may include a display 

30 27, speakers 29, or other means. 

31 The navigation system 10 uses a map database 30 stored on a storage 

32 medium 32. The storage medium 32 is installed in the drive 14 so that the map 




1 database 30 can be read and used by the navigation system. The storage medium 32 

2 may be removable and replaceable so that a storage medium with an appropriate 

3 map database for the geographic region in which the vehicle is traveling can be 

4 used. In addition, the storage medium 32 may be replaceable so that the map 

5 database 32 on it can be updated easily. 

6 In one embodiment, the storage medium 32 is a CD-ROM disc. In an 

7 alternative embodiment, the storage medium 32 may be a PCMCIA card in which 

8 case the drive 14 would be substituted with a PCMCIA slot. Various other storage 

9 media may be used, including fixed or hard disks, DVD (digital video disks) or 

10 other currently available storage media, as well as storage media that may be 

1 1 developed in the future. 

12 The map database 30 contains information about the roadway network in the 

13 geographic region. Figure 2 shows a map illustrating physical geographic features in a 

14 portion of a geographic region. Figure 3 is a block diagram illustrating the data 

15 entities that represent the geographic features in Figure 2. In one embodiment, the 

16 map database 30 includes node data and segment data. Node data represent physical 

17 locations in the geographic region (such as roadway intersections and other positions) 

18 and segment data represent portions of roadways between the physical locations 

19 represented by nodes. Each road segment in the geographic region is represented by a 

20 road segment data entity (i.e., a record) in the map database 30. Each road segment 

21 data record in the map database has two nodes which represent the coordinate 

22 positions at each end of the road segment represented by the road segment data 

23 record. The data records include information that can be used during route 

24 calculation, such as turn restrictions, vehicle access, restricted driving conditions, etc. 

25 (The terms "nodes" and "segments" represent only one terminology for describing 

26 these physical geographic features and other terminology for these feature is intended 

27 to be encompassed within the scope of these concepts.) 

28 In one embodiment of the map database 30, the roadways are classified by rank 

29 in accordance with the importance or significance of the roadway for vehicle travel. 

30 For example, roadways of rank "0" may be alleyways and side streets, roadways of 

31 rank "1" may be primary city streets, roadways of rank "2" may be highways, and so 

32 on. Each road segment data record in the map database 30 also identifies the rank of 
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1 the corresponding portion of the roadway that it represents. As illustrated in Figure 3, 

2 the map database 30 for a geographical area may be stored in layers. The lowest layer 

3 ("0") contains records that represent roadways of all ranks, the next higher layer (" 1") 

4 contains roadways of rank " 1" and higher, the next higher layer ("2") contains 

5 roadways of rank "2" and higher, and so on. The road segment records may include 

6 additional information about the represented road segments, such as the speeds along 

7 the represented road segments, turn restrictions, weight restrictions, the names of the 

8 roads that the segments are parts of, address ranges along the road segments, and so 

9 on. In an alternative embodiment, the geographic database 30 may include more than 

10 one rank of road in a single layer. The map database 30 may include additional 

1 1 information as well. 

12 Referring again to Figure 1, the navigation application software program 18 is 

13 loaded from the non-volatile memory 16 into a RAM 20 associated with the processor 

14 12 in order to operate the navigation system. The navigation system 10 uses the map 

15 database 30 stored on the storage medium 32, possibly in conjunction with the 

16 output 26 from the positioning system 24, to provide various navigation features and 

17 functions. The navigation software program 18 may include separate applications 

18 (or subprograms) that provide these various navigation features and functions. 

19 These functions and features may include route calculation, map display, vehicle 

20 positioning (e.g., map matching), route guidance (wherein detailed directions are 

21 provided for reaching a desired destination), destination resolution capabilities, and 

22 other functions. 

23 

24 II. THE ROUTE CALCULATION TOOL PROGRAM 

25 A.. Overview 

26 Referring to Figure 4, in the navigation software program 18 the route 

27 calculation features are provided by a route calculation tool 40. The route calculation 

28 tool 40 is a computer program that may be used as part of the navigation software 

29 program 18. The route calculation tool 40 determines routes between specified 

30 locations. If used with a navigation software program 18 in a navigation system 

3 1 installed in a vehicle, the route calculation tool 40 determines routes for the vehicle to 

32 travel. The route calculation tool 40 may be used in combination with the map 



- 7- 



1 database 30 and other programs or subprograms within the navigation program 18, or 

2 even with other programs outside the navigation program 18 or navigation system 10. 

3 Specifically, in the navigation software program 18, the route calculation tool 40 

4 interfaces with a navigation application 47. The navigation application 47 may include 

5 appropriate programs that provide the remainder of the navigating functions provided 

6 by the navigation system 10, such as route guidance, vehicle positioning, the user 

7 interface, and so on. Alternatively, the navigation application 47 may operate as a 

8 manager that uses other tool programs, such as a geo-coding tool 90, a route guidance 

9 tool 91, a map display tool, and so on, to implement one or more of the other various 

10 navigation functions. 

11 In a preferred embodiment, the route calculation tool 40 is provided as a 

12 module that is relatively portable and that can be incorporated into different kinds of 

13 systems. The route calculation tool may be compiled into an executable module with 

14 the navigation application or may be used as a standalone program. In a preferred 

15 embodiment, the route calculation tool 40 employs an object oriented approach to both 

16 its programming, its use of data, and its relationship to the navigation application 47. 

17 Each object that forms the route calculation tool receives input data and generates 

18 output data according to a predefined function and may invoke methods on other 

19 objects. In one present embodiment, each object has its own private memory which is 

20 opaque to other objects. In the disclosed embodiment, an object may be used to 

21 convey data from one object to another object or may be used to transform data 

22 received as input. The route calculation tool 40 is written in the C programming 

23 language although in alternative embodiments other programming languages may be 

24 used, such as C + + or Java. In general, programming languages that support 

25 object oriented programming are preferred. 
26 

27 B. Objects input to and output from the 

28 Route Calculation Tool Program 

29 In one embodiment, the route calculation tool 40 comprises a route calculation 

30 object 50. This route calculation object 50 receives as input as least two waypoint 

3 1 objects 100 and provides an output in the form of a route object 60. In a present 

32 embodiment, the route calculation object 50 may also use as input a configuration 

33 object 64, a vehicle object 68, a time object 69, and an input route object 72. (There 
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1 may be additional objects in addition to these. For example, there may be an object 

2 that defines specific application-defined callbacks, i.e., wherein the application may 

3 want partial solutions, as described below.) 
4 

5 (I). The configuration object 

6 Referring to Figure 5, the configuration object 64 is a data structure that holds 

7 parameters 64(1) . . 64(n), which are used to control the route calculation object 50. 

8 Some or all of these parameters may be configurable by the end-user. Some of these 

9 parameters may include items, such as weighting factors, that may be used in route 

10 calculation. For example, these parameters may include "avoid highways," "avoid 

1 1 U-turns," "determine shortest route," "determine quickest route," etc. These 

12 parameters may also include the maximum layer of map data (as represented in Figure 

13 3) at which route searching is to be performed and whether the route searching should 

14 use logical or physical suppression to enforce the maximum layer. Some configurable 

15 parameters in the configuration object 64 may be selected by the navigation system 

16 manufacturer or by a service technician and thus may not be configurable by the end- 

17 user. The data included in the configuration object 64 is stored in a re-writable and 

IX non-volatile memory of the navigation system, such as the non-volatile memory 16 (in 

19 Figure 1). 

20 

21 (2). The vehicle object 

22 Referring to Figure 6, the vehicle object 68 is a data structure that includes data 

23 68(1) . . 68(n) that provide the characteristics of the vehicle for which the route will be 

24 calculated by the route calculation tool 40. Under some circumstances, characteristics 

25 of the vehicle may affect generation of the route. For example, the vehicle object 68 

26 may include data that indicates that the vehicle is a truck having a given weight and 

27 number of axles. In such a case, the route searching tool 40 ensures that the calculated 

28 route include only roadways with weight limits that allow such a vehicle. In another 

29 example, the vehicle object 68 may include information indicating that the vehicle is a 

30 passenger vehicle having more than one person on board. The route searching tool 40 

3 1 can then include lanes restricted to multiple passenger vehicles. The data included in 

32 the vehicle object 68 is stored in a re-writable and non-volatile memory of the 

33 navigation system, such as the non-volatile memory 16 (in Figure 1). Some or all of 
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1 the data in the vehicle object 68 may be configurable by the end-user. Alternatively, 

2 some or all may be determined by the navigation system manufacturer or a technician. 

3 

4 (3). The (output) route object 

5 Referring to Figure 7, the output route object 60 is illustrated. The route 

6 object 60 is a data structure generated by the route calculation object 50. The output 

7 route object 60 includes a single route determined by the route calculation object 50. 

8 The route is comprised of a list 60(1) of road segment data records (such as the 

9 segment data records described in connection with Figure 3) that represent portions of 

10 roadways that together comprise the calculated route. The route object 60 also 

1 1 contains waypoint information 60(2) describing the origin, destination, and 

12 intermediate waypoints and indicating where they are located relative to the list 60(1) 

13 of road segments. (This waypoint information is contained in a plurality of route 

14 waypoint data structures 400 derived from the route calculation object waypoint data 

15 structure 550, described below.) The output route object 60 is provided to the 

16 navigation application 47 that uses the list 60(1) of road segment data records and the 

17 waypoint information 60(2) in the route object 60 to provide various navigation 

18 functions, such as provide instructions to the driver, generate graphical display maps of 

19 the route, and so on. 

20 In addition, the route object 60 may include other items of data. These items 

21 may include a start date/time 60(3). This item of data may be derived from the start 

22 date/time 69(1), described below. The route object 60 may also include a route 

23 generation start dateAime~60(4). This item of data corresponds to the date and time at 

24 which the route was calculated. The route object 60 also may include a copy of the 

25 vehicle object 68, described above. The route object 60 may also include data 60(5) 

26 that indicates the version of the geographic database that was used in developing the 

27 list of segments 60(1) The route object 60 may also include an "s-flag" item of data 

28 60(6). This item of data indicates whether particular kinds of segment or node records 

29 are included in the list of segments 60(1). In particular, in some databases, there are 

30 segment records that represent aggregations of individual road segments and node 

3 1 records that represent a plurality of nodes. If either of these kinds of records is 

32 included in the list of segments 60(1), the s-flag item of data 60(6) is set. In addition, 

33 the route object 60 may include other kinds of data 60(n). 
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1 

2 (4). The (input) route object. 

3 When providing certain functions as described in detail below, the route 

4 calculation object 50 uses a route object as an input. In Figure 4, a route object, 

5 labeled "72", is shown being used as an input to the route calculation object 50. A 

6 route object used as an input may have a similar or identical structure as the output 

7 route object 66, shown in Figure 7. The route object used as an input includes at least 

8 a list of road segment data records that comprise a calculated route. The route object 

9 used as an input to the route calculation object 50 may be a route object 60 that had 

10 previously been calculated by the route calculation object 50. Alternatively, the route 

1 1 object 72 used as an input to the route calculation object 50 may be provided by 

12 another program, such as the navigation application 47. 

13 The route calculation object 50 uses a route object as an input when 

14 information about a previously calculated route is considered when calculating a 

15 subsequent route. For example, a route object may be used as an input to the route 

16 calculation tool 40 when calculating an alternative route to the previously calculated 

17 route represented by the input route object. 
18 

19 (5). The time object. 

20 Referring to Figure 8, the time object 69 is a data structure that includes data 

21 69(1) . . 69(n) concerning a date and time which are used by the route calculation tool 

22 40. Under some circumstances, time characteristics may affect generation of the route. 

23 For example, during certain hours of the day, there are turn restrictions that prohibit 

24 turns from certain roads onto other roads. The navigation system may allow the end- 

25 user to specify a time at which the route will be begun. This may be provided via the 

26 user interface 3 1 . The navigation application 47 may include data 69(1) in the time 

27 object 69 that indicates the start time for the route calculation. The route calculation 

28 tool 40 uses the data in the time object 69 to account for routing time restrictions 

29 when calculating the route. The time object 69 may include other data 69(n) as well. 

30 Provision of the time object 69 is optional. The time object may also be used to allow 

31 the navigation application 47 to specify (and the navigation 40 tool to interpret) a 

32 date/time as either year/month/day/hour/minute or "seconds-since-a-base-date/time" 

33 and to convert between the two formats. 
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I 

2 (6). The waypoint objects 

3 (i) Wavpoinl object overview 

4 As mentioned above in connection with Figure 4, the route calculation tool 40 

5 receives as input two or more waypoint objects 100. A waypoint object 100 is a data 

6 structure used to represent a waypoint. A waypoint refers to a location through which 

7 the route to be calculated by the route calculation object 50 is constrained to pass. 

8 In order to calculate a route, the route calculation tool 40 requires at least two 

9 waypoint objects 100, one that represents the waypoint corresponding to the origin 

10 and another that represents the waypoint corresponding to the destination. One or 

11 more additional waypoint objects 100 may be provided to the route calculation tool 40 

12 to represent waypoints corresponding to one or more intermediate locations between 

13 the origin and destination. 

14 Figure 1 1 shows the data included in a waypoint object 100. The waypoint 

15 objects 100 are formed or created by the navigation application 47 that provides the 

16 waypoint objects 100 to the route calculation tool 40. Alternatively, the waypoint 

17 objects 100 may be provided by one or more other programs or routines that are part 

18 of the navigation program 18 that create the waypoint objects 100 and provide them to 

19 the navigation application 47, which in turn provides them to the route calculation tool 

20 40. (In an alternative embodiment, the waypoint objects 1 00 may be provided by a 

21 program outside of the navigation program 1 8 or even outside of the navigation 

22 system 10. In one present embodiment, the waypoint object is created by the 

23 navigation application, but it uses one or more functions in the route calculation tool to 

24 do it. The contents of the waypoint object may therefore be opaque to the 

25 application.) 
26 

27 (ii) Navigation position ob jects 

28 Referring again to Figure 4, in one embodiment, the navigation application 47 

29 uses some or all of the information in navigation position objects 56 to create the 

30 waypoint objects 100. In one embodiment, a geocoding tool 90 creates the navigation 

31 position objects 56 which are provided to the navigation application 47. The geo- 

32 coding tool 90 may create the navigation position objects 56, in part, from information 

33 57 provided to it from the navigation application 47. For example, this information 57 
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1 may include coordinates or other information derived from input from the end-user via 

2 the user interface 3 1 (of Figure 1). This input information may include, for example, a 

3 street address, a point-of-interest, crossroad, or some other location representing a 

4 desired destination, or a desired intermediate location. The geocoding tool 90 may 

5 also create a navigation position object 56 from information derived from the 

6 positioning system 14. This information from the positioning system 14 may also be 

7 provided to the geocoding tool 90 by way of the navigation application 47 and may be 

8 used to create a navigation position object 56 that represents an origin of a route 

9 corresponding to a present position of the vehicle in which the navigation system 10 is 

10 located. 

1 1 Figure 9 is a diagram illustrating the structure for a navigation position object 

12 56. Referring to Figure 9, the navigation position object 56 is a data structure that 

13 contains information about a location in terms of data in the geographic database 40. 

14 This position may be expressed as a locus data structure 92 (described below). 

15 Alternatively, the position may be expressed in various other ways. In addition to the 

16 locus data 92, the navigation position object 56 may include geographic coordinate 

17 data 93 (e.g., latitude, longitude) associated with the locus 92. In a present 

18 embodiment, each navigation position object 56 includes only a single locus 92. The 

19 navigation position object 56 may also include other data 56(n). 

20 

2 1 (in) The locus 

22 Figure 10 is a diagram illustrating the locus data structure 92. The locus data 

23 structure 92 identifies a position along a road segment represented by a road segment 

24 data record in the map database 30. The locus data structure 92 includes (1) data 94 

25 identifying one road segment data record (e.g., by a segment identifier or ID) 

26 associated with the locus, (2) a spot 95 along the road segment represented by the 

27 road segment record 94 at which the locus is located, and (3) the side 96 of the road 

28 segment represented by the road segment record 94 on which the locus resides. In a 

29 present embodiment, in order to define a spot 95 along a road segment, each road 

30 segment, regardless of size, may be divided into 256 subsegments, each of which 

31 defines a position along the road segment. The information in the locus data structure 

32 92 may be defined by the routine, such as the geocoding tool 90, that provides 

33 navigation position objects 56 to the navigation application 47 which in turn uses 
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1 navigation position objects 56 to create waypoint objects 100 which are provided to 

2 the route calculation tool 40. 

3 Referring to Figures 4, 9, and 10, the geocoding tool 90, or a similar program, 

4 translates origin/destination information into the locus data structure 92, or similar data 

5 structure, and provides this locus data 92 in navigation position objects 56 to the 

6 navigation application 47. The origin/destination information may be derived from 

7 input from the end-user via the user interface 3 1 (of Figure 1). For example, the end- 

8 user may input a destination of "300 South Wacker Drive, Chicago Illinois." The 

9 geocoding program 90, or some other program that it may utilize, determines that the 

10 specified address is located at position Y along segment X and is on the left-hand side 

1 1 of segment X in order to form the locus data structure. The geocoding program 90 

12 stores this locus information 92 in a navigation position object 56 which is provided to 

13 the navigation application 47. Once the navigation application 47 receives the locus 

14 information 92 in the navigation position object 56, it uses the locus information 92 to 

15 create a waypoint object 100 which is provided to the route calculation tool 40 in 

16 order to perform a route calculation. 

17 Origin information may also be derived from a position determined by the 

18 positioning system 14 (of Figure 1). This information is also used to create a locus 92 

19 which is stored in a navigation position object 56 that corresponds to the origin. This 

20 navigation position object 56 corresponding to the origin is provided to the navigation 

21 application 47 and used by the navigation application 47 to create a waypoint object 

22 100 corresponding to the origin which is provided to the route calculation tool 40. 

23 (In an alternative embodiment, the navigation application 47 may obtain the 

24 locus information 92 from a program and use it to form a waypoint object 100 without 

25 obtaining it in the form of a navigation position object.) 
26 

27 (iv) Components of (he Waypoint Object 

28 Figure 1 1 is a diagram illustrating the components of a waypoint object 100. 

29 Figure 12 is a map illustrating a waypoint represented by a waypoint object. The 

30 waypoint object 100 is a data structure provided to the route calculation tool 40. As 

31 mentioned above, the waypoint object 100 represents a location through which the 

32 route to be calculated by the route calculation object 50 is constrained to pass. 
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1 Waypoint objects 100 are used to represent the origin of the route, the destination of 

2 the route, and any intermediate locations along the route. 

3 Waypoint objects may be temporary data structures, permanent structures, or 

4 semi-permanent structures. For example, permanent or semi-permanent waypoint 

5 objects may be stored in the non-volatile storage 16 (of Figure 1) or even in the 

6 geographic database 30. The navigation system may allow an end-user to store 

7 favorite or commonly visited destinations and may provide for storage of waypoint 

8 objects 100 in the non-volatile memory 16 to represent these end-user selections. 

9 Waypoint objects may also be pre-formed and stored in the geographic database 30 for 

10 certain destinations. 

1 1 Using the navigation position objects 56, as well as other information, the 

12 navigation application 47 forms at least two waypoint objects 1 00 which are provided 

13 to the route calculation tool 40. Referring to Figure 1 1, each waypoint object 100 

14 includes the following information (1) optionally, position data 102 of the waypoint, 

15 (2) optionally, a description 104 of the waypoint, (3) optionally, a delay 1 12 associated 

16 with the waypoint, and (4) one or more portals 106. 

17 The geographical position 102 of the waypoint object 100 is provided by the 

18 navigation application 47. The geographic coordinates 102 are the actual geographic 

19 coordinates (i.e., latitude and longitude) of the waypoint, as distinguished from the 

20 coordinates of an entrance to or exit from the waypoint or a position located along a 

21 road segment in the geographic database 30. 

22 The description 1 04 of the waypoint is a name, or other textual description, by 

23 which the waypoint is com monl y known. For example, the description may be "Sears 

24 Tower." The data included in the description 104 is supplied by the navigation 

25 application 47 when it forms the waypoint object 100. The description 104 of the 

26 waypoint object is an optional item of data. 

27 The delay 1 12 may be associated with an waypoint object that represents an 

28 intermediate waypoint. The delay 1 1 2 represents an amount of time to be spent at or 

29 in the vicinity of the intermediate waypoint. A value for the delay is specified in an 

30 input provided from the end-user via the user-interface 3 1 (of Figure 1). The 

3 1 navigation application 47 associates this delay value with other information that 

32 represents the intermediate waypoint to form a waypoint object that represents the 

33 intermediate waypoint. For example, an end-user may desire a route between an origin 
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! and a destination which passes through an intermediate waypoint representing a 

2 restaurant location. If the end-user plans to spend one hour at the restaurant, that hour 

3 would be the delay for the intermediate waypoint that represents the restaurant. The 

4 delay 1 12 of a waypoint object is an optional item of data. 
5 

6 (v) Portals 

I As illustrated in Figure II, each waypoint object 100 has one or more portals 

8 106 . A portal 106 is a data structure that represents one of the entrances or exits of 

9 the waypoint represented by the waypoint object 100. In some cases, a waypoint is 

10 accessible via more than one road segment in the map database 30 or by more than one 

II position on the same road segment. For example, referring to Figure 12, a waypoint 

12 object may be used to represent a parking garage. The parking garage is located at an 

13 intersection and has a separate entrance and exit located at different positions along a 

14 single segment of a roadway and has another entrance located along another segment. 

15 Under these circumstances, the navigation application 47 uses more than one portal 

16 106 in forming the waypoint object 100 that represents the parking garage. Each 

17 entrance to the parking garage is represented by a portal and each exit from the 

18 parking garage is represented by a portal. 

19 Each portal 106 in the waypoint object 100 includes a locus 92 (as described 

20 above), a direction 107, and a side flag 109. The locus 92 information included in each 

21 portal data structure 106 may be derived from a separate navigation position object 56 

22 which is provided to the navigation application 47, as explained above. Because each 

23 waypoint may have multiple entrances and/or exits, each of which is represented by a 

24 separate portal 106, the navigation application 47 may use several navigation position 

25 objects 56 to obtain the loci 92 to form the portals 106 required for the waypoint 

26 object 100 that represents the waypoint. 

27 As mentioned above with respect to Figure 10, a locus data structure 92 

28 identifies (1) a segment data record, (2) a position along the road segment represented 

29 by the road segment data record, and (3) a side of the road segment represented by the 

30 segment data record. When used in connection with a portal 106, the locus data 

3 1 structure 92 identifies the road segment data record that represents one of the road 

32 segments from which the waypoint represented by the waypoint object can be entered 

33 by means of the portal (if the locus represents an entrance) or from which the waypoint 



- 16- 



1 represented by the waypoint object can be exited by means of the portal (if the locus 

2 represents an exit). As further mentioned above, this locus data structure 92 also 

3 identifies the position along the road segment represented by the road segment record 

4 at which the access to or from the waypoint is permitted. The locus data structure 92 

5 also identifies the side of the road segment represented by the road segment record on 

6 which the waypoint is located. 

7 In addition to the locus data 92, the portal data structure 106 also includes 

8 direction information 107 and side flag information 109. The direction information 

9 107 indicates a direction associated with the portal 92. The direction information 107 

10 indicates whether the waypoint can be entered from the associated portal, exited from 

11 the associated portal, or both entered and exited. If the waypoint object represents an 

12 intermediate stop along a route, a route calculated to the waypoint will be constrained 

13 to use a portal for which the direction 107 indicates that entrance into the waypoint is 

14 permitted (or both entrance and exit is permitted). On the other hand, a route 

15 calculated from an intermediate waypoint will be constrained to use a portal for which 

16 the direction 107 indicates that exit from the waypoint is permitted (or both entrance 

17 and exit is permitted). 

18 The enforce side information 109, if set, requires that the route begin (or end) 

19 on the side of the street specified in the locus, depending upon whether the portal is 

20 being used as an exit from or an entrance to the waypoint. When the enforce side data 

21 109 is set, it means that the exit from (or entrance into) the waypoint represented by 

22 the portal has to made on the side of the street upon which the waypoint is located 

23 (i.e., the street cannot be crossed). The enforce side flag 109 is not used for one-way 

24 streets. 
25 

26 C. Route Calculation Object 

27 The route calculation tool 40 includes a route calculation object 50. The route 

28 calculation object 50 uses the information in two or more of the waypoint objects 100 

29 to store data in a route object 60 which is returned to the navigation application 47, as 

30 described below. The route calculation object 50 may be provided with additional 

31 objects, including the configuration object 64, the vehicle object 68, and so on, as 

32 mentioned above. 
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1 (I), Initial formation of components of the Route Calculation Object 

2 As mentioned above, the waypoint objects 100 provided to the route 

3 calculation tool 40 include at least two waypoint objects 100, one that represents an 

4 origin and one that represents a destination. Additional waypoint objects 100 may be 

5 provided to the route calculation tool to represent intermediate stops that the end-user 

6 desires to make along the way between the origin and the destination. 

7 Prior to performing route calculation, each route calculation object 50 creates 

8 several new data structures. These data structures are internal to each route 

9 calculation object 50 and therefore are not necessarily shared between them. These 

10 data structures created by each route calculation may be temporary data structures or 

1 1 may be permanent or semi-permanent data structures. These data structures are 

12 created, manipulated, modified, and may be destroyed during operation of the route 

13 calculation tool 40. For purposes of creating, modifying, manipulating, and destroying 

14 these data structures, appropriate programming, such as a route calculation engine 

15 160, may be provided. The presence and operation of the route calculation engine 160 

16 is internal to the route calculation object 50 and therefore is opaque to the navigation 

17 application 47. 

18 Referring to Figure 13, included among the data structures created by the route 

19 calculation object 50 are route calculation object waypoint structures 450, search tree 
2() objects 140, and priority queue objects 150. Component parts of these objects, such 

21 as gates 124, are also created by the route calculation object 50. 

22 A route calculation object waypoint data staicture 450 is created for each 

23 waypoint object 100 provided to the route calculation object 50. In Figure 13, a route 

24 calculation object waypoint data structure 450(ORIGIN) is created for the origin 

25 waypoint and a route calculation object waypoint data structure 450(DEST) is created 

26 for the destination waypoint. The data included in each route calculation object 

27 waypoint data structure 450 is shown in Figure 20. Some of the data included in the 

28 route calculation object waypoint data structure 450 is derived from the corresponding 

29 waypoint object 100 provided to the route calculation object 50. The description 404 

30 in the route calculation object waypoint data structure 450 corresponds to the 

31 description 104 included in the waypoint object 100 for the corresponding origin, 

32 destination, or other waypoint. Likewise, the position 402 included in the route 
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1 calculation object waypoint data structure 450 corresponds to the position 102 in the 

2 waypoint object 100 for the corresponding origin, destination, or other waypoint. 

3 For each route calculation waypoint data structure 450 in the route calculation 

4 object 50, except the route calculation object waypoint data structure 450(ORIGIN) 

5 that represents the origin, the time of travel 416, the distance 418, and the cost 414 

6 hold values that are developed as part of the process of route calculation. 

7 The time of travel 416 holds a value that indicates the cumulative total time to 

8 travel a route from the origin waypoint to the waypoint represented by the route 

9 calculation object waypoint data structure 450. This value 416 is determined by 

10 adding the times of travel of the road segments that comprise a solution route from the 

1 1 origin waypoint to the waypoint represented by the route calculation object waypoint 

12 data structure 450. Alternatively, the time of travel 416 may include the travel times 

13 for traversing both segments and nodes. 

u The distance of travel 418 holds a value that indicates the cumulative total 

15 distance to travel a route from the origin waypoint to the waypoint represented by the 

16 route calculation object waypoint data structure 450. This value 4 1 8 is determined by 

17 adding the distances of the road segments that comprise a solution route from the 

18 origin waypoint to the waypoint represented by the route calculation object waypoint 

19 data structure 450. 

20 The cost of travel 414 holds a value that indicates the cumulative total cost to 

21 travel a route from the origin waypoint to the waypoint represented by the route 

22 calculation object waypoint data structure 450. The cost 1 14 refers to that measurable 

23 quantity that is being minimized during a search relative to the origin waypoint. The 

24 navigation application 47 provides the item to be used for the cost to the route 

25 calculation object (e.g., in the configuration object). The cost may be configurable by 

26 the end-user. For example, the end-user may desire to find the quickest route, and 

27 therefore time is the cost item being minimized. If the end-user desires the shortest 

28 route, distance is the cost item being minimized. Other kinds of cost items may be 

29 selected, including custom cost functions that incorporate combinations of various 

30 factors. Other cost values that can be minimized include items such as minimizing 

31 U-turns and avoiding highways. This cost value 414 is developed as the route is being 

32 calculated by adding the costs of the road segments that are added to a solution route 
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1 from the origin waypoint to the waypoint represented by the route calculation object 

2 waypoint data structure 450. 

3 In the route calculation object waypoint data structure 450(ORIGIN) 

4 corresponding to the origin waypoint, the time 416, distance 418, and cost 414 are 

5 zero. 

6 If a waypoint object 100 provided to the route calculation tool 40 includes a 

7 delay 1 12, the route calculation object waypoint data structure 450 formed from the 

8 waypoint object 100 also includes a delay 421 which corresponds to the delay of the 

9 waypoint object 100. 

10 Each route calculation object waypoint data structure 450 also includes the 

1 1 portal data 106 from the corresponding waypoint object 100. 

12 Before the route calculation tool 40 begins to calculate a route, the sequence in 

13 which the intermediate waypoints are visited may be reordered. According to one 

14 embodiment, if the navigation application 47 requests that the route calculation tool 40 

15 reorder the intermediate waypoints (via a function call or other appropriate means), the 

16 intermediate waypoints are reordered based upon distance from the origin. 

17 Alternatively, the navigation application may provide an alternative reordering 

18 algorithm, function or ordering to use for reordering. If no instructions regarding 

19 reordering are provided by the navigation application 47 to the route calculation tool 

20 40, the route calculation tool 40 begins to calculate a solution route that visits the 

21 intermediate waypoints in the order in which they are provided to the route calculation 

22 tool 40. 

23 

24 (2). Initial formation of the Search Tree Ob jects 

25 Referring again to Figure 13, to perform route searching, the route calculation 

26 object 50 creates and uses at least two search tree objects 140. The two search trees 

27 objects include an outbound search tree object 140(OUT) and an inbound search tree 

28 object 140(1N). 

29 The search tree objects 140 are parts of the route calculation object 50. The 

30 search tree objects 140 are used internally by the route calculation object 50 and thus 

3 1 are transparent to the remainder of the route calculation tool 40. Each search tree 

32 object 140 defines and holds information used for route searching. Specifically, each 

33 search tree object 140 holds a search tree 141 (shown in Figures 15 and 16) formed of 
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1 gates 124 associated with a respective one of the waypoints. When calculating a route 

2 between an origin waypoint and a destination waypoint without any intermediate stops, 

3 the outbound search tree 141(OUT) is associated with the origin waypoint and the 

4 inbound search tree 141 (IN) is associated with the destination waypoint. However, if 

5 there are intermediate waypoint stops, multiple inbound and outbound search tree pairs 

6 are created and used successively by the route calculation object 50, one pair for each 

7 leg of the route. For example, if there is one intermediate waypoint, a first outbound 

8 search tree 141(OUT) is used for the origin waypoint and a first inbound search tree 

9 141(IN) is used for the intermediate stop waypoint. After a route between the origin 

10 and the intermediate waypoint stop is calculated, the route calculation object 50 

1 1 creates two new search trees. A second outbound search tree 141 (OUT) is used for 

12 the intermediate waypoint and a second inbound search tree 141(IN) is used for the 

13 destination waypoint. Additional search tree pairs may be formed and used if there is 

14 more than one intermediate stop. (As explained further below, for certain kinds of 

15 searches each search tree object may be associated with more than one waypoint.) 

16 During route calculation, the search tree 141 in each search tree object 140 is 

17 grown. The search tree 141 is grown by expanding gates 124. Gates 124 are data 

18 structures that define both a position and a direction along a path, as explained below. 

19 When a gate 124 is expanded, its one or more successor gates 124 are identified and 

20 added to its respective search tree, thereby growing the tree. Each search tree 141 is 

21 grown toward a single point. This single point towards which the search tree grows is 

22 referred to as a focus 143. Each search tree object 140 has only a single focus 143. 

23 However, in a present embodiment, the focus 143 of a search tree object 140 is 

24 configurable, and thus may be chosen to be any point. For example, in a present 
2> embodiment, the focus I43(OUT) of the outbound search tree 141(OUT) may be 

26 selected to coincide with the position of the waypoint associated with the inbound 

27 search tree. This point may be the destination waypoint or an intermediate waypoint. 

28 Alternatively, the focus 143 (OUT) of the outbound search tree 141 (OUT) may be 

29 selected to coincide with a point on the inbound search tree 14 1 (IN). If the inbound 

30 search tree 141(IN) has already been grown, it is preferred to select a point on the 

3 1 inbound search tree 141 (FN), such as the point that is closest to the origin waypoint, as 

32 the focus of the outbound search tree 141(OUT). Alternatively, the focus 143(OUT) 

33 of the outbound search tree 141 (OUT) can be selected to coincide with any other 



-21 - 



1 suitable point., or another point determined to optimize the direction of growth of the 

2 search tree. 

3 Similarly, the focus 143(IN) of the inbound search tree 141 (IN) may be 

4 selected to coincide with the waypoint associated with the outbound search tree. This 

5 waypoint may be the origin waypoint or an intermediate waypoint. Alternatively, the 

6 focus 143 (IN) may be selected to be any point on the outbound search tree 141 (OUT). 

7 In other alternatives, the focus 143 (IN) of the inbound search tree 141(rN) can be 

8 selected to coincide with any other suitable point determined to optimize the direction 

9 of growth of the search tree, as well as the vehicle position (as explained below with 
10 respect to rerouting). 

1 1 

12 (3). Formation of gates in general 

13 As mentioned above, each of the search trees 141 is formed of one or more 

14 gates 124. All the gates in each search tree 141 , except for the initial (or seed) gates, 

15 are formed by expanding gates to find successor gates which are added to the search 

16 tree 141 thereby growing it. The initial gates 124 in each search tree 141 are seed 

17 gates 108. During route calculation, the search tree 141 grows from these seed gates 

18 108 (i.e., the "roots" of the search tree 141) toward the single focus point 143 

19 associated with the respective search tree object 140. 

20 Referring to Figure 17, there is a diagram representing the data structure of a 

21 gate 124. Each gate 124 includes data which define both a position and a direction 

22 along a path. To define a position, each gate 124 includes (or refers to) an item of 

23 data-L25 that defines a position in the geographic database. If the gate 124 is other- 

24 than-a-seed-gate, this item of data 125 is a node data record (in Figure 2) in the 

25 geographic database 30. If the gate 124 is other-than-a-seed-gate, the node data 

26 record in this item of data 125 is referred to as the associated node of the gate. The 

27 position of the gate 124 corresponds to the position of its associated node. 

28 To define a direction along a path, each gate 1 24 includes (or refers to) another 

29 node data record 127. This node record included in this item of data 127 is referred to 

30 as the target node of the gate. If the gate is other-than-a-seed-gate, the target node 

31 127 represents one of the endpoints of a road segment represented by a segment data 

32 record whose other endpoint is represented by the node data record corresponding to 

33 the associated node 125. Accordingly, a gate 124 (other-than-a-seed-gate) defines a 
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1 position by means of a node and a direction from that position by means of another 

2 node located at the other end of a segment that links the two nodes. Thus, the gate 

3 124 defines both a position (by means of the item of data 125) and a navigable 

4 direction from the position (via the road segment represented by the segment record 

5 whose endpoint corresponds to the target node which is accessible ) toward the target 

6 node 127. 

7 In addition to a position and a direction, each gate 124 identifies a path in the 

8 direction from the position. To identify this path, the gate 124 identifies a road 

9 segment record that links its associated node and its target node. The gate data 

10 structure 124 includes an item of data 129 identifying this segment data record. This 

1 1 identification 129 of the segment may include a segment database ID, a pointer to a 

12 segment database ID, or other appropriate reference. 

13 In forming gates, the routing attributes associated with the nodes and segments 

14 are examined to ascertain that travel in the desired direction between the two nodes via 

15 the segment that links them is permitted before a gate is formed. For example, with 

16 respect to the gates in the outbound search tree, the target node is required to be 

17 accessible from the associated node via the segment that links them. In the outbound 
IK tree, if a road segment is a one-way street directed toward a first node from a second 

19 node, the second node is not accessible from the first node via this segment, and 

20 therefore a gate cannot be formed linking these two nodes in this direction via this 

21 segment. 

22 On the other hand in the inbound search tree, the segments and nodes are 

23 evaluated for valid travel in the opposite (i.e., reverse) direction. With respect to the 

24 gates in the inbound tree, the associated node is required to be accessible in a direction 

25 back from the target node via the segment that links them. For example, in the 

26 inbound search tree if a first end of a road segment is being evaluated as a potential 

27 associated node and the road segment is a one-way street directed toward the node at 

28 the other end of the segment, the segment is not accessible (in this direction) and 

29 therefore a gate is not formed linking these two nodes in the inbound search tree. (For 

30 purposes of this disclosure, accessibility of the target node relative to the associated 

31 node is understood to take into account the opposite directions of travel of the 

32 outbound search tree and the inbound search tree.) 
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1 If the gate is other-than-a-seed-gate, it also includes a reference 13 1 to its 

2 predecessor gate. This reference 131 may be pointer, or other suitable data 

3 referencing structure. The reference 1 3 1 in each gate can be used to reconstruct the 

4 route from a seed gate to any successor gate, and vice versa. 
5 

6 (4). Seed gates 

I Gates 124 used as seed gates 108 have a similar structure as gates used as 

8 other-than-seed-gates. When a gate is used as a seed gate, some of the data included 

9 in it represent different features compared to when a gate is used other-than-as-a-seed 
10 gate. 

I I When a gate is used as a seed gate, it defines a location into (or out of) an 

12 associated waypoint. Referring to Figure 13, the information used to form the seed 

13 gates for each search tree 140 is derived from the corresponding waypoint object 100 

14 provided to the route calculation object 50. When the route calculation object 50 is 

15 provided with at least two waypoint objects 100, one for the origin and one for the 

16 destination, it uses the information in these waypoint objects 100, specifically the 

17 portal information, to form seed gates for the outbound search tree and the inbound 

18 search tree, respectively. These seed gates are added to the appropriate search trees. 

19 Thus, in forming the seed gates for the outbound search tree object 140(OUT), the 

20 data in the waypoint object 100(ORIGIN) that represents the waypoint of the origin is 

21 used to form seed gates 108 that are added to the outbound search tree 141 in the 

22 outbound search tree object 140(OUT) in Figure 13. Likewise, in forming the seed 

23 gates for the inbound search tree object 140(IN), the data in the waypoint object 

24 100(DEST) that represents the waypoint of the destination is used to form seed gates 

25 108 that are added to the inbound search tree 141 in the inbound search tree object 

26 140(1N) in Figure 13. 

27 Figure 18 shows the data structure of a gate 124 used as a seed gate 108. If 

28 the gate 124 is used as a seed gate, the item of data 125 that represents the position of 

29 the gate corresponds to one of the portals 106 from the waypoint object 100. In each 

30 seed gate 108, the item of data 125 corresponding to the position of the gate is the 

3 1 locus of one of the portals 1 06 of the associated waypoint object. As mentioned 

32 above, a portal 106 represents an entrance to the waypoint represented by the 

33 waypoint object, an exit from the waypoint represented by the waypoint object, or 
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1 both. Each portal of a waypoint object 100 is used to form one or two seed gates in 

2 its respective search tree object 140. 

3 Each seed gate also includes a target node 127 which is used to define a 

4 direction. The target node 127 defines a direction into or out of the location 

5 represented by the locus 92 included in the item of data 125 corresponding to the 

6 position of the seed gate. The node data record in the target node 127 represents the 

7 road segment endpoint that can be accessed (in a forward direction for the outbound 

8 search tree and in the opposite direction for the inbound search tree) from the location 

9 represented by the portal of the waypoint. Thus, the seed gate defines a direction from 

10 the geographic position represented by the locus 92 of a portal of a waypoint towards 

1 1 a node at one end of the segment on which the portal lies, thereby linking the portal to 

12 the end node of the segment and thereby to the rest of the road network in the 

13 geographic region. The segment 129 of the seed gate 108 corresponds to the segment 

14 upon which the locus 92 of the portal 106 is located. Since a seed gate has no 

15 predecessor, it does not point to a predecessor and accordingly has no data 

16 corresponding to the predecessor pointer 131. 

17 As mentioned above, a portal 106 includes a locus 92 which defines a spot 95 

18 along a road segment 94. In forming seed gates, if travel from the portal 106 is 

19 permissible along its associated segment in both directions, the portal 106 may be used 

20 to form two seed gates 1 08. One seed gate would have as its target node the node at 

21 one end of the segment associated with the locus, and the other seed gate would have 

22 as its target node the node at other end of the segment associated with the locus. If 

23 travel from the portal 106 is permitted in only on e direction, the portal 106 may be 

24 used to form only one seed gate 108. 
25 

26 (5), Initial check for solution route 

27 At this stage, before either search tree is grown, the inbound search tree 

28 141 (IN) and the outbound search tree 141 (OUT) are checked to see whether a 

29 solution route exists between the origin and destination waypoints. A solution route 

30 exists when a seed gate in one search tree corresponds to a seed gate (and thus the 

31 same segment) in the other search tree. After forming all the seed gates in one of the 

32 search trees, as each seed gate is formed in the other search tree, its segment ID (i.e., 

33 in data item 129) is compared to the segment ID in all the gates in the opposite tree 
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1 whose associated nodes are the same as the target node of the new gate. (Gates are 

2 stored in lists indexed by the node ID of the associated node to facilitate this check). If 

3 a match is found, it is an indication of a complete path from origin to destination and a 

4 potential solution. If a solution route is found without expanding any of the seed 

5 gates, the solution route between the origin waypoint and the destination waypoint 

6 comprises a single road segment record. If a solution route is found at this stage, the 

7 destination is f just down the block' from the origin. The solution route, consisting of a 

8 single segment record, is placed into a list of potential solution routes 500 (in Figure 

9 1 5). Assuming all criteria for further searching have been met, the potential solution 
10 route from the list 500 is stored in an output route object 60. This route output object 
l L 60 is provided to the navigation application 47 which in turn may provide it to another 

12 program (such as a maneuver generation program) in the navigation application 

13 program 18 from which instructions are provided to the end-user via the user interface. 

14 

15 (6). Initial expansion o f gates 

16 If a solution route is not found after all the seed gates are formed and added to 

17 their respective search trees, each of the seed gates is expanded thereby growing the 

18 search trees. Because the search trees initially include only seed gates, these gates are 

19 expanded first. A seed gate is expanded by forming its successor gates and adding 

20 these successor gates to its respective search tree. Referring to Figure 14, starting 

21 with the seed gates 108, each search tree is grown by creating successor gates 124. 

22 The associated node of a successor gate is the same node as the target node of the gate 

23 which the successor gate succeeds. The successor gates 1 24 of the seed gates 1 08 are 

24 formed using the target nodes of the seed gates 108. Like the seed gates 108, these 

25 successor gates 124 are defined and used by the route calculation object 50 during 

26 route calculation. Like the seed gates, these successor gates 124 allow the route 

27 calculation tool 40 to define both a position and a direction. 

28 Where a target node of a gate (seed or other-than-seed) represents an endpoint 

29 of multiple segments which can be accessed through that node, the gate will have 

30 multiple successor gates, one for each segment. Where a target node of a gate 

3 1 represents an endpoint of only one segment which can be accessed through that node 

32 (taking into account the forward and backward directions of the outbound and inbound 

33 trees, respectively), the gate will have only one successor gate. Where no segment can 
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1 be accessed through the node represented by the target node of a gate, the gate with 

2 have no successor gates. 

3 In both the outbound search tree 141(OUT) and the inbound search tree 

4 141 (IN), the successor gates of the seed gates are determined and added to their 

5 respective search trees. At this stage, the inbound search tree 141(IN) includes the 

6 seed gates 108 from the destination waypoint and the immediate successor gates 124 

7 of these seed gates 108. The outbound search tree 141(OUT) contains the seed gates 

8 108 of the origin waypoint and the immediate successor gates 124 of these seed gates 

9 108. In the search tree objects of Figure 14, each gate 124 is stored with its respective 

10 associated node. 

1 1 At this stage, as the inbound search tree 141(IN) and the outbound search tree 

12 141(OUT) are grown by determining the successor gates of the seed gates, as each 

13 successor gate is formed, it is checked to see whether a solution route exists between 

14 the origin and destination waypoints. As mentioned above, a solution route exists 

15 when a gate in one search tree corresponds to a gate (and thus the same segment) in 

16 the other search tree. As each successor gate of the seed gates is formed, its segment 

17 ID is compared to the segment ID's of all the gates in the opposite tree whose 

18 associated nodes are the same as the target node of the new gate. If a match is found, 

19 it is an indication of a potential solution. If a solution route is found, the solution 

20 route, consisting of the segment records in each search tree that meet at the matching 

21 gate, is placed into the list of potential solution routes 500 (in Figure 15). Unless 

22 applicable search configuration criteria require that searching be continued for 

23 additional solution routes, the potential solution route is stored in the output route 

24 object 60. 

25 (In an alternative embodiment, as each of the seed gates associated with the 

26 origin is added to the outbound search tree, it is expanded to form several successors 

27 which are also added to the outbound tree. This is done to move the outermost gates 

28 of the outbound search tree away from the origin waypoint and out of a possibly 

29 restricted traffic area that may not be easily accessed by growth of the inbound search 

30 tree. Some areas include traffic restrictions in which the accessibility of a road 

31 segment depends upon the characteristics of a preceding segment. Areas that prohibit 

32 through traffic are examples of these kinds of traffic restricted areas. If the origin 

33 waypoint is in such an area, a route can be calculated away from it, but not necessarily 
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! into it, since road segments in these traffic restricted areas are not necessarily available 

2 when searching is being done for the inbound search tree.) 

3 

4 (7). Initial formation of the Priority Queue Objects 

5 Referring again to Figure 13, when performing route searching, the route 

6 calculation object 50 creates and uses two priority queue objects 150. In a preferred 

7 embodiment, each search tree object 140 is associated with a priority queue object 

8 1 50. The priority queue objects include an outbound priority queue object 1 50(OUT) 

9 associated with the outbound search tree object 140(OUT) and an inbound priority 

10 queue object 150(IN) associated with the inbound search tree object 140(IN)- 

1 1 Like the search tree objects 140, the priority queue objects 150 are parts of, 

12 and are used internally by, the route calculation object 50. Thus, they are transparent 

13 to the remainder of the route calculation tool 40. Each priority queue object 150 

14 contains a list that assigns a priority value to each unexpanded gate in its respective 

15 search tree object. The priority values are used to determine which gates in the 

16 respective search tree object are to be expanded during route calculation. (Figure 13 

17 represents an initial stage of the operation of the route calculation object 50 after the 
IK seed gates have been formed and added to each search tree object, but prior to 

19 assigning a priority of any of the gates in the priority queue objects 1 50.) 
20 

2 1 (8). Use of priority queue objects 

22 If a solution route is not found after all the successor gates of the seed gates 

23 are formed and added to their respective search trees, one of the search trees is grown 

24 by expanding one of its gates, after which a check is made to determine whether one of 

25 the successor gates formed by expanding the gate matches one of the gates in the other 

26 search tree. In a present embodiment, the inbound search tree 141 (IN) is grown first, 

27 although in an alternative embodiment, the outbound search tree 141(OUT) is grown 

28 first. 

29 The search tree to be grown first may have a plurality of successor gates of its 

30 one or more seed gates. Although it is possible to expand each successor gate to find 

3 1 a solution route, such an approach would waste considerable computing resources and 

32 likely generate many unusable routes. In a present embodiment, it is preferred to 

33 expand one gate at a time and to select the gate to be expanded based upon a definable 
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1 criteria. In a present embodiment, the route calculation object 50 uses the priority 

2 queue objects 1 50(IN) and 1 50(OUT) for the purpose of determining which gate to 

3 expand in each respective search tree object 140. Each priority queue object 150 

4 contains a pointer or other means of reference to each gate in its respective search tree 

5 which has not yet been expanded. Thus, when the priority queue object 150(IN) is 

6 formed for the inbound search tree 141(IN), pointers (or other suitable references) to 

7 the successor gates 124 formed from the seed gates 108 of the destination waypoint 

8 are stored in the priority queue object 150(IN) associated with the inbound search tree 

9 141 (IN). (The priority queue 150 contains a reference or pointer to each gate that has 

10 not yet been expanded. The gates themselves are contained in the search tree. 

1 1 Unexpanded gates in the search tree are also referred to as "raw gates.") 

12 Referring to Figure 14, in the inbound priority queue object 150(IN), an order 

13 of priority is assigned to these raw successor gates 124 using a search algorithm 170. 

14 Any known method or algorithm 170 may be used for this purpose. For example, the 

15 method used may be the A* algorithm or the Dykstra algorithm. To use the A* 

16 algorithm, the route calculation object 50 calls the algorithm 1 70 with a pointer to the 

17 data in each of the gates which are referenced in the priority queue 1 50. The route 
ix calculation engine 1 60 may also pass the focus or a pointer to the focus to the 

19 algorithm 170. The algorithm evaluates each of the gates referenced in the priority 

20 queue relative to the focus 143(IN). An advantage provided by this approach is that 

21 the method used for route searching is configurable. For example, the A* algorithm 

22 may be modified to the Dykstra algorithm by setting the heuristic variable to zero. A 

23 default algorithm may be provided with the route calculation tool 40. The navigation 

24 application 47 can provide an algorithm in substitution of the default algorithm. 

25 Alternatively, other route searching techniques or algorithms may be substituted. For 

26 example, when the A* algorithm is used, the highest priority gate is the one with the 

27 lowest overall combined actual and heuristic costs. Using the algorithm 170, a 

2X weighting is assigned to each of the unexpanded gates referenced in the priority queue 

29 150(IN). 

30 Using the priorities assigned to the listing of gates in the priority queue 

31 150(LN), the gate 124 in the inbound search tree 141 with the highest priority identified 

32 in the priority queue 1 50(1N) is expanded. This expanding may be done by the route 

33 calculation engine 160 or by any other suitable programming associated with the route 
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1 calculation object 50. The route calculation engine 160 creates the successor gates of 

2 the gate being expanded and adds these successor gates to the inbound search tree 

3 14 1 (FN). The process of creating successor gates includes the step of querying the 

4 map database 30 (represented in Figures 1 and 2) to find each segment data record that 

5 has the target node of the gate being expanded as one of its endpoints. Once all these 

6 road segment data records are obtained, they are examined to ascertain which, if any, 

7 of them can be used to form valid successor gates. Starting from the target node of 

8 the gate with the highest priority, each segment that connects to that node is examined 

9 to determine whether access is permitted from the segment across the target node into 

10 the segment associated with the gate being expanded. A turn restriction at the target 

1 1 node may prohibit access from the segment associated to the potential successor gate 

12 into the segment associated with the gate being expanded, and therefore a successor 

13 gate cannot be formed using that segment. Likewise, a one way street restriction along 

14 the segment associated with the potential successor gate may prohibit access along that 

15 segment in a desired direction, and therefore a successor gate cannot be formed using 

16 that segment. 

17 Note that in the inbound search tree, the direction of travel is toward the target 
IS node of the gate being expanded. Therefore, the segment associated with the gate 

19 being expanded is required to be accessible from the segment associated with the 

20 potential successor gate across the target node associated with the gate being 

21 expanded. In the outbound search tree, the direction of travel is opposite. In the 

22 outbound search tree, the direction of travel is away from the target node of the gate 

23 being expanded and therefore, the segment associ ated w ith the potential successor gate 

24 is required to be accessible from the segment associated with the gate being expanded 

25 across the target node associated with the gate being expanded. 

26 Time restrictions may also be taken into account when determining valid 

27 successor gates. As mentioned above, the end-user may specify a start time for the 

28 route. This start time is provided to the route calculation object via the time object 69. 

29 If a start time is provided, restrictions based on the estimated time of arrival at a gate 

30 are taken into account. In a preferred embodiment, if the end-user has not specified a 

3 1 start time for the route, all time-based restrictions may be assumed to be in effect since 

32 the route calculation tool 40 does not necessarily assume that the end-user intends to 

33 start the route at the present time. Thus, if a left turn is prohibited at an intersection 
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1 between 3 P.M. and 6 P.M., the restriction will be treated as in effect if the end-user 

2 has not specified a start time. 

3 If the gate having the highest priority (from the priority queue 1 50([N)) has no 

4 valid successor gates, the gate with the next highest priority in the priority queue 

5 150(IN) is selected and expanded, if possible, 

G In a present embodiment, the inbound search tree 14 1(IN) is grown first (until 

7 some predetermined threshold is met, such as distance traveled toward the focus), and 

8 then the outbound search tree 141(OUT) is grown. In an alternative embodiment, the 

9 outbound search tree 141(OUT) is grown first and then the inbound search tree 

10 141 (IN) is grown. In further alternative embodiments, one of the search trees is not 

1 1 grown at all and only the other search tree is grown until a solution route is found. 

12 The inbound search tree 140(1N) is grown from the destination towards the 

13 focus 143(IN), which may be the position of the origin or another point. The 

14 outbound search tree 140(OUT) is grown from the origin towards a focus 143(OUT), 

15 which may be the position of the destination or another point. 

16 As each valid successor gate is formed, it is added to its respective search tree. 

17 Thus, when a gate in the inbound search is being expanded, each of its successor gates 

18 is added to the inbound search tree 141 (IN), and when a gate in the outbound search is 

19 being expanded, each of its successor gates is added to the outbound search tree 

20 141 (OUT). As each successor gate is added to its respective search tree, it is checked 

21 to see whether the segment associated therewith (i.e., the segment 129) is already 

22 present in either of the search trees. If a successor gate of a gate being expanded is 

23 present in the other search tree, at least one solution route has been found. 

24 Under some circumstances, a new successor gate may correspond to a gate 

25 which already exists in the same search tree that contains the gate being expanded. 

26 This can occur if a gate can be accessed by more than one route through the road 

27 network. If the new successor gate already exists in the search tree, then the actual 

28 cost 132 in the gate structure 124 (in Figure 17) of the path leading to the existing gate 

29 is compared to the actual cost of following the new path leading to the gate, and the 

30 lower cost path is selected. Where the old path has the lower cost, then it is checked 

3 1 to see whether the new path has any more valid successor gates and, if not, the new 

32 path is closed. Where the new path has the lower cost, then it is checked to see 

33 whether the old path has any more valid successor gates and, if not, the old path is 
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1 closed. If the old path does have valid successors, then their pointers are changed to 

2 point to the new raw gate as their parent, and the cost of the new path is propagated to 

3 the successor gates as well as to any further successor gates through such successor 

4 gates. 

5 If all the successor gates of a gate being expanded are not already in either 

6 search tree, the successor gates are all added to the inbound search tree 141. For each 

7 new successor gate 124 that is added to the search tree 140(IN), a pointer or reference 

8 to the new gate is added to the priority queue 150(IN) for the inbound search tree 

9 140(IN). The pointer (or other reference) to the now expanded gate is taken out of 

10 the priority queue 1 50(IN). (A gate that has been expanded may be referred to as an 

1 1 "open gate ") After the pointer to the expanded gate is removed from the priority 

12 queue 150(IN) and the pointers to the new raw gates are added to the priority queue 

13 150(IN), the algorithm 170 is used to determine which of the unexpanded gates 

14 identified in the priority queue has the highest priority. This gate is selected for 

15 expansion and the process continues, as described above. 

16 The inbound search tree 140(IN) is grown until either a predefined threshold is 

17 reached or a solution route is found. Upon reaching the predefined threshold, growth 

18 of the inbound search tree 141(1N) is stopped and the outbound search tree 141(OUT) 

19 is grown until a solution route is found or another predefined threshold applicable to 

20 the outbound search tree 141 (OUT) is reached. In a preferred embodiment, these 

21 thresholds are preferably configurable by the navigation application 47. Threshold 

22 parameters may be stored in the configuration object 64 (in Figure 4) which is 

23 provided to the_rout_e calculation object 50. The threshold parameter for the inbound 

24 search tree may be defined as a predefined distance from the destination waypoint, a 

25 number of search iterations, the travel time from the destination waypoint, the number 

26 of gates, the cost from the destination waypoint, or some other definable value. 

27 If the inbound search tree 141 (IN) reaches its predefined threshold before a 
2H solution route is found, the outbound search tree 141(OUT) is grown. The outbound 

29 search tree 14 1 (OUT) is grown in a manner similar to the inbound search tree 141 (IN) 

30 until a route solution is determined or until a predetermined threshold configured for 

31 the outbound tree is reached. In a preferred embodiment, each tree is grown only 

32 once. If a solution route is not found when the outbound tree is grown to its 

33 predefined threshold, a failure condition is returned indicating that a solution route has 
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1 not been found within the predetermined constraints. The end-user may be given an 

2 opportunity to have the navigation system continue searching, whereupon the route 

3 calculation object is instructed by the navigation application 47 to continue growing 

4 either or both search trees. In an alternative embodiment, growth of the search trees 

5 may continue to alternate until a solution route is found. 

6 

7 (9). - Finding of solution routes 

8 Growth of either of the search trees 141 may be stopped prior to reaching the 

9 predetermined threshold if a solution route is found. A solution route is found when 

10 one search tree meets the other search tree. Specifically, a solution route is found 

1 1 when a raw (unexpanded) gate in the search tree being grown corresponds to a gate 

12 (and thus the same segment) in the other search tree. This is graphically illustrated in 

13 Figure 15. Note that if the inbound search tree 141 (IN) is not configured to have a 

14 threshold, it will continue to be grown until it meets a successor gate of a seed gate of 

15 the origin waypoint in the outbound search tree 14 1 (OUT). If the inbound search tree 

16 141(IN) is not configured to have a threshold, the search proceeds in a one-ended 

17 manner from the destination towards the origin. The origin waypoint seed gates and 

18 their successors are present in the outbound search tree 141 (OUT), even if the inbound 

19 search tree 14l(IN) has no threshold. Thus, a potential solution route is found by 

20 detecting when the two search trees meet. 

21 After a potential solution route is found, route searching may be continued to 

22 find additional solution routes between the two waypoints until a termination criterion 

23 is met. The termination criterion can be some combination of number of potential 

24 solutions, quality (cost) of the solutions, time elapsed in the search, etc. A present 

25 embodiment finds one solution, then expands all the gates in the priority queue, 

26 without adding any new gates to the priority queue. This may produce additional 

27 solution candidates. The termination criterion may be stored in the configuration 

28 object 64 of Figure 4, 

29 Each new solution is placed in the list of potential solutions 500 (in Figure 15). 

30 When the search termination criterion is satisfied, the best solution is copied to the 

31 output route object 60. All segment records from both search trees that lie along the 

32 route to the common gate are stored in the route object 60. 
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1 If there are more than two waypoints, the route calculation object is used to 

2 calculate a solution route for each leg of the entire route in the manner described 

3 above. Thus, each solution route calculated in this manner forms only a part of the 

4 entire final solution route. Therefore, if there is a single intermediate waypoint, a 

5 solution route is determined by the route calculation object 50 in the manner described 

6 above for the portion of the entire route between the origin and the intermediate 

7 waypoint. Then, another solution route is determined by the route calculation object 

8 50 in the manner described above for the portion of the entire route between the 

9 intermediate waypoint and the destination waypoint. The list of segments 500 for each 
10 of these solution routes between each of the waypoints is stored serially in the route 

1 J calculation object 50 in order to form the entire solution route that links all the 

12 waypoints. 

13 As mentioned above in connection with Figure 7, the route object 60 also 

14 includes a list 60(2) that includes route object waypoint data structures 400. This list 

15 60(2) is developed and included in the route object 60 as the route calculation object 

16 50 calculates the legs of the solution route between each waypoint pair for the entire 

17 route. There is an entry in the list 60(2) of route object waypoint data structures 400 

18 for each waypoint in the final entire route. The data included in each route object 

19 waypoint data structure 400 is illustrated in Figure 16. The data included in each route 

20 object waypoint data structure 400 includes some or all the data that had been 

21 developed and included in the route calculation object waypoint data structure 450 

22 during route calculation. 

23 In addition to the items of data from the route calculation object waypoint data 

24 structure 450, the route object waypoint data structure 400 includes several additional 

25 items of information. For example, the route object waypoint data structure includes 

26 an index 424 to the segment list 60(1). This index 424 to the segment list 60(1) is 

27 used in the route object 50 to indicate to which segment in the list of segments 60(1) 

28 of the route object 60 the waypoint corresponds. 

29 The route object waypoint data structure 400 includes data 420 that specifies 

30 what type of waypoint the route object waypoint data structure 400 represents. For 

31 example, the data 420 may specify that the route object waypoint data structure 400 

32 represents an "origin", a "destination", or an "intermediate" waypoint. Other suitable 
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1 types may be defined. This data 420 is derived from the navigation application 47 by 

2 way of the waypoint objects 100 provided to the route calculation object 50. 

3 The route object waypoint data structure 400 also includes data 422 that 

4 identifies one or two loci 92. This data 422 in the route object waypoint data structure 

5 400 is used to indicate the entrance, exit, or both an entrance and an exit, of the 

6 waypoint represented by the route object waypoint data structure 400. For example, if 

7 the route object waypoint data structure 400 represents the origin waypoint, the data 

8 422 identifies the locus 92 that represents the exit from the origin waypoint to embark 

9 upon the calculated route. For the route object waypoint data structure 400 that 

10 represents the destination waypoint, the data 422 identifies the locus 92 that represents 

1 1 the entrance into the destination waypoint to complete the calculated route. For 

12 intermediate waypoints, the data 422 may identify one or two loci 92. It may be 

13 required that an intermediate waypoint be entered at one location and exited at 

14 another. Thus, if the calculated route identifies a separate entrance into and exit from 

15 an intermediate waypoint, the route object waypoint data structure 400 that represents 

16 the intermediate waypoint includes two loci 92 in the data 422 to represent the 

17 separate entrance into and the exit from the intermediate waypoint. Since it is possible 

18 that an intermediate waypoint can be entered and exited from the same location, the 

19 route object waypoint data structure 400 that represents an intermediate waypoint may 

20 include only one locus 92 in the data item 422. 

21 

22 111. ALTERNATE FEATURES OF THE ROUTE CALCULATION TOOL 

23 Although the embodiments of the route calculatio n too l 40, described above, 

24 provide for significant advantages for route searching when used as part of a 

25 navigation application program 18, many of the significant advantages and benefits 

26 derive from the features that the tool enables or makes more efficient. Some of these 

27 features are described below. 
28 

29 A, Implementing rank suppression 

30 One present embodiment of the route calculation tool provides for 

31 implementing a rank suppression feature. When a rank suppression feature is 

32 implemented with the route calculation tool, a quality solution route can be found 

33 quickly. Rank is described above in connection with Figure 2. As mentioned above, 
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1 each road segment is assigned a rank (e.g., 0-4) which corresponds to a functional 

2 classification of the represented road. When using the rank suppression feature with 

3 one present embodiment of the route calculation tool, segment data records having a 

4 rank below a certain threshold rank are suppressed during a portion of the route 

5 calculation process, thereby reducing the amount of time needed to find a quality 

6 solution route. As described below, there are several different ways that the route 

7 calculation tool can implement rank suppression. 

8 As described above, during route calculation when gates are being expanded in 

9 each search tree, the map database 30 is queried for the purpose of determining valid 

10 successor gates. In one embodiment, an examination is made of each segment record 

1 1 that has as one of its endpoints the target node of the gate being expanded to 

12 determine whether it can be used to form a valid successor gate. In one embodiment, 

13 the rank suppression feature is implemented to reduce the number of possible gates to 

14 examine and create during route calculation. By reducing the number of possible gates 

15 being examined and created, processing time is reduced and generally a solution route 

16 can be found more quickly. As implemented in the route calculation tool, rank 

17 suppression uses predetermined criteria to specify under which conditions rank 

18 suppression applies. When properly implemented, the rank suppression feature 

19 eliminates from consideration possible gates that are not likely to form part of a 

20 solution route. However, by suppressing the formation of these gates using rank 

21 suppression, the need to evaluate these gates, in the priority queue for example, is 

22 obviated thereby reducing processing time. 

23 In one embodiment, the rank suppression feature is configurable. 

24 Configuration parameters for rank suppression may be stored in the configuration 

25 object 64 or may be programmed into the route calculation tool 40. The configuration 

26 parameters may include some or all of the following: 

27 (a) the distance (of the gale) from the origin waypoint (for the inbound 

28 search tree); 

29 (b) the distance from the destination waypoint (for the outbound search 

30 tree); 

31 (c) the distance from the gate of the outbound tree that is closest to the 

32 destination waypoint; 
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1 (d) the distance from the gate of the inbound tree that is closest to the 

2 origin waypoint; 

3 (e) the density of the road network (which may be measured by the rate of 

4 the geographical growth of the search tree); 

5 (f) the total number of nodes expanded in the search tree; and 

6 (g) the highest rank of the gate in the inbound tree (this only applies for the 

7 outbound tree). 

8 In general, these parameters configure the rank suppression feature so that it 

9 begins suppressing gates at some point after some initial number of gates have been 

10 expanded. In general, rank is not used to suppress gates close to a waypoint. 

1 1 By suppressing the segment data records of certain ranks at certain stages of 

12 the route calculation process, the route calculation tool avoids the computations 

13 associated with forming gate structures for the suppressed segments, thereby speeding 

14 up the process of finding a solution route. 

15 (J J. Logical and physical rank suppression Rank suppression may be 

16 implemented either logically or physically. Using logical rank suppression, the route 

17 calculation tool 40 (in Figure 4) uses layer "0" of the map database 30 (in Figure 2) 

18 during route calculation. Map database layer "0" contains road segment data records 

19 representing road segments of all ranks. Logical rank suppression may be applied as 

20 part of the step of forming valid successor gates. As mentioned above, during route 

21 calculation, the map database 30 is queried for the purpose of determining valid 

22 successor gates. As described above, each segment record that has as one of its 

23 endpoints the target node of the gate being expanded is examined to determine 

24 whether it can be used to form a valid successor gate. To implement logical rank 

25 suppression, as each of these segment records is being examined, an additional test (or 

26 filtering) step is applied that suppresses any segment record having a rank below a 

27 configurable specified rank. This effectively prevents any successor gate being formed 

28 in the direction along a road segment connected to the target node being expanded 

29 when the road segment record that represents the road segment has a rank below the 

30 specified rank. This method of logical rank suppression can be implemented rigidly or 

3 1 flexibly. Rigid rank suppression always suppresses consideration of segment records 

32 having a rank below a specified rank when the criteria are met. Flexible rank 

33 suppression can be operated dynamically taking into account various other criteria. 
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1 Using physical rank suppression, the road segment records are retrieved only 

2 from the layer of the map database 30 that contains segment records at or above the 

3 specified rank. By eliminating segment records of lower ranks from consideration in 

4 route searching, fewer road segment records need be evaluated or explored to 

5 determine the solution route (i.e., fewer gates will be generated in the search tree for 

6 expansion). The layer to be used may be determined for each gate independently of 

7 the layers used for the other gates. 

8 (2). Alternative rank suppression implementation According to one 

9 embodiment of the route calculation tool that uses rank suppression, a suppression 
JO strategy is based on the distance of the geographical position of a road segment 

1 1 relative to the specified start and end locations of the journey. Referring to Figure 21, 

12 there is a map that illustrates the concepts associated with this embodiment. Figure 21 

13 shows road segments leading from one of the waypoints. In this figure, the waypoint 

14 is the destination. These road segments represented in Figure 21 are represented by 

15 gates in the inbound search tree. These road segments illustrate the condition of the 

16 inbound search tree after it has been grown by expanding gates. (For the sake of 

17 clarity, the road segments that are represented by gates in the outbound search tree are 

18 not illustrated in this figure. It is understood that there is at least one gate that 

19 represents at least one segment in the outbound search tree.) 

20 As described above, when each search tree object is formed, it is associated 

21 with a focus. The focus of a search tree is the point toward which it is configured to 

22 grow. The focus is configurable so that it can be determined to be any point. 

23 Referring to Figure 21, there is illustrated a focus of the inbound search tree. In the 

24 map of Figure 21, the focus may be chosen to correspond to the position of the origin 

25 or to any other point, such as a point on the outbound search tree. 

26 During operation, the route calculation tool defines one or more zones. Each 

27 zone is defined by a zone boundary Z_l, Z_2 . . . Z_k. The zone boundaries are 

28 circular-shaped areas encircling the waypoint from which the search tree grows. The 

29 width of each zone may be fixed, or may be varied as a function of the density of the 

30 local road network, as described below. 

31 When the route calculation tool implements rank suppression using zones, any 

32 road segment outside the outermost zone boundary Z_k is eliminated unless it is of the 

33 highest rank. Elimination of any other road segment depends on its rank and the 
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1 corresponding zone in which it is located. Thus, within the innermost zone, Z_l, alt 

2 road segments of all ranks are used, i.e., no ranks are suppressed. Outside zone Z_l, 

3 but within zone Z_2, road segments of rank 0 are suppressed, but all other road 

4 segments may be explored. At each larger zone, another corresponding rank of road 

5 segments is suppressed. (The number of zones may be equal to the number of ranks, 

6 or may be different. For example there may be fewer zones than ranks and more than 

7 one rank may ; be suppressed when moving outward from one zone to another,) 

8 As mentioned above, the sizes of the zones may be determined based upon the 

9 density of the road network in the vicinity of the waypoint. The density of the road 

10 network can be determined as the search tree is being grown. As the inbound search 

1 1 tree is grown by expanding gates, a road density value is determined by comparing the 

12 number of gates that are in the inbound search tree (also referred to as the "tree 

13 height") to the distance of the gate being expanded from the waypoint of the search 

14 tree. For example, in a relatively dense road network, such as in an urban area, there 

15 are many road segments per square kilometer. Therefore, as the search tree is being 
10 grown, a relatively small actual distance is traveled from the waypoint compared to a 
17 relatively large number of road segments that are examined in the vicinity of the 

IK waypoint. On the other hand, in a relatively sparse road network, such as in a rural 

19 area, there are few road segments per square kilometer. Therefore, as the search tree 

20 is being grown, a relatively large distance is traveled from the waypoint compared to 

21 the number of road segments examined in the vicinity of the waypoint. 

22 Accordingly to one embodiment, a default size is selected for one or preferably 

23 each of the zones. These default sizes are selected to be the smallest permitted sizes 

24 for the widths of each of the zones. These smallest permitted sizes would correspond 

25 to the sizes of each the zones in a dense road network, such as in an urban area. These 

26 default sizes may be stored as parameters in the configuration object or elsewhere in 

27 the navigation system. Then, during route calculation as the search tree is being 

2H grown, a determination is made of the road density at some interval of tree growth. 

29 This interval may correspond to when each gate is added to a search tree, or after 

30 every ten gates are added to a search tree, or after every hundred gates are added to a 

31 search tree, and so on. (The interval may also be stored as a configuration parameter.) 

32 At each interval, a road density determination is made by comparing the tree height 

33 (i.e., where the height of the search tree corresponds to the total number of gates in the 
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1 search tree) to the distance from the waypoint of the most recently added gate. If the 

2 road network is relatively sparse, a relatively large distance will have been traveled 

3 from the waypoint for a given number of gates. This distance is compared to a 

4 distance traveled from the waypoint for the same number of gates in a dense road 

5 network, such as the one used to model the default zone width. If this comparison 

6 indicates that the road network is relatively sparse, the zone size is increased. This 

7 may be accomplished by applying a proportionate scaling factor to the default zone 

8 size. Thus, if a default zone boundary size, Zjdefault, of 1-2 kilometers is established 

9 for the innermost zone boundary, Z_l (wherein the default size corresponds to a 

10 preferred size of the innermost zone boundary Z_l in a dense road network), and the 

1 1 road network is measured to be relatively sparse, the size of the inner zone boundary 

12 Z_l may be increased proportionately by a factor related to the road network density. 

13 The proportionate scaling factor to be applied may be based upon empirical or 

14 experimental analysis. For example, experiments may show that an inner zone width of 

15 10 km provides the best and fastest routes for airal areas and that an inner zone width 

16 of 1.5 km provides the best and fastest routes for urban areas. If the route calculation 

17 tool measures a road density that is between these two extremes, an appropriate 

18 scaling factor is applied to determine a size between 10 km and 1 .5 km for the zone 

19 width proportionate to the measured density. It is noted that different default zone 

20 sizes may be appropriate for different countries or regions within a country. These 

21 default zone sizes may be determined experimentally. 

22 According to one implementation of this embodiment, rank suppression is also 

23 applied outside of the outermost zone in a manner to improve calculation of quality 

24 routes. During operation of the route calculation tool, when gates are being expanded 

25 in a search tree, the route calculation object defines a focus gap. The focus gap of a 

26 search tree is defined to be the distance from the focus of the search tree to the gate in 

27 the search tree closest to the focus. The focus gap is used as a search reference 

28 parameter by the route calculation object and is updated, if necessary, at each step of 

29 tree growth. Figure 21 shows the unexpanded gate H, on the inbound search tree that 

30 is closest to the focus. Figure 21 also shows the focus gap. (This method disclosed in 

31 (his embodiment may be used in implementations that do not include gates, search 

32 trees, or similar structures.) 
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1 During operation, the route calculation tool defines a focus ring. A focus ring 

2 is a donut-shaped area at a calculated distance from the focus and encircling the focus 

3 of the search tree. A focus ring is shown in Figure 21. The focus ring in Figure 21 is 

4 defined between RJ and R_3. The inner boundary of the focus ring, R_l corresponds 

5 to the focus gap. The outer boundary of the focus ring R__3 is calculated during route 

6 calculation, as explained below. 

7 In between the inner and outer boundaries, R_l and RJ3, of the focus ring, the 

8 focus ring may be partitioned into a set of nested sub-rings. In Figure 21, two nested 

9 sub-rings are shown. An inner sub-ring is defined between R_l and R_2, and an outer 

10 sub-ring is defined between R_2 and R_3. In further embodiments, additional sub- 

11 rings may be used. 

12 When the route calculation tool implements rank suppression using a focus 

13 ring, any road segment located outside the outer boundary R_3 of the focus ring is 

14 suppressed unless it is of the highest rank. Thus, referring to Figure 21, the road 

15 segments labeled A, C, D, and E are shown to be located outside the outer boundary 

16 R_3 of the focus ring. Unless these road segments, labeled A, C, D, and E, are of the 

17 highest rank (i.e., rank 4 in one embodiment), these segments are suppressed from 

18 further consideration as potential solution routes. 

19 Elimination of any other road segment depends on its rank and the 

20 corresponding sub-ring in which it is located. For example, referring to Figure 21, 

21 within the innermost sub-ring, which is defined as the region between R_l and R_2, no 

22 road segments are suppressed. In Figure 21, the road segments labeled F, G, and H 

23 are shown to be located within the inner sub-ring between R_l and R 2. According to 

24 this embodiment, the road segments labeled F, G, and H, are not suppressed, even if 

25 they have a low rank. For example, if the road segment labeled F is a rank 0 road, it is 

26 not suppressed because it is in the innermost focus ring. Thus, the road segments 

27 labeled F, G, and H are maintained as available gates in the inbound search tree. 

28 The suppression of a road segment depends upon its rank and the sub-ring in 

29 which it is located. For example, in Figure 21, the road segment labeled B is in the 

30 sub-ring between R_2 and R_3. This road segment B is suppressed if it is has a rank 

31 of 0, but is not suppressed if it has a rank greater than 0. (In Figure 21, only two sub- 

32 rings are shown for the sake of clarity, but in a present embodiment, the number of 
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1 rings may be equal to the number of ranks.) A road segment of rank i will be 

2 eliminated if it is not in ring RJ or a ring smaller than RJ. 

3 Using this embodiment, all road segments are searched in small neighborhoods 

4 of the start and end locations (which correspond to the waypoints of each search tree). 

5 At each tree growth step, the route calculation tool updates a set of parameters which 

6 are used to guide the search. At each gate expansion, the search tree is augmented 

7 with only those successor gates formed from unsuppressed road segments. 

8 Using this embodiment, a road of low or medium rank can be evaluated for a 

9 solution route if its geographical distance to the tree focus point is shorter than the tree 

10 focus gap plus the focus ring width. As can be appreciated from examining Figure 21, 

1 1 by not suppressing lower ranked segments within the focus ring, there exists the 

12 possibility that promising lower ranked roads may be incorporated into a solution 

13 route. In order to be used in a solution route, a route that incorporates such lower 

14 ranked roads would still have to provide a lower overall cost compared to any of the 

15 other potential routes being explored. However, using the disclosed embodiment, 

16 lower ranked roads may be considered even if they may be located relatively far from a 

17 waypoint. This embodiment still suppresses consideration of lower ranked roads that 

18 are unlikely to form low cost solution routes, such as the roads outside the outer 

19 boundary of the focus ring. Thus, by selectively suppressing roads in this manner, a 

20 quality route can be calculated relatively quickly. 

21 As mentioned above, the sizes of the focus ring and its sub-rings are based 

22 upon the density of the road network. As described above in connection with 

23 determining the sizes of the z ones a round the waypoint, the density of the road 

24 network can be determined as the search tree is being grown. As the inbound search 

25 tree is grown by expanding gates, a road density value is determined by comparing the 

26 number of gates that are in the inbound search tree (also referred to as the "tree 

27 height") to the distance of the gate being expanded from the waypoint of the search 

28 tree. 

29 Like the zones, default sizes may be selected for the focus ring and its sub- 

30 rings. These default sizes are selected to be the smallest permitted sizes for the widths 

31 of the focus ring and its sub-rings. These smallest permitted sizes would correspond to 

32 the sizes of the focus ring and its sub-rings in a dense road network. A default focus 

33 ring width of 5 km may be used with the sizes of each of the sub-rings proportionate to 
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1 the size of the entire focus ring. These default sizes may be stored as parameters in the 

2 configuration object or elsewhere in the navigation system. 

3 As the search tree is being grown, a determination is made of the road density 

4 at some interval of tree growth, as described above. A road density determination is 

5 made by comparing the tree height to the distance from the waypoint of the most 

6 recently added gate. If this comparison indicates that the road network is relatively 

7 sparse, the widths of the focus ring and sub-rings are increased. This may be 

8 accomplished by applying a proportionate scaling factor to the default ring sizes. Like 

9 the sizes for the zones, a proportionate scaling factor to be applied may be based upon 

10 empirical or experimental analysis. For example, experiments may show that a focus 

1 1 ring width of 10 km provides the best routes quickly for rural areas and that a focus 

12 ring width of 5 km provides the best routes quickly for urban areas. If a road density is 

13 measured that is between these two limits, an appropriate scaling factor is applied to 

14 determine a size between 5 and 10 km for the focus ring width proportionate to the 

15 measured density between these limits. It is noted that different default sizes may be 

16 appropriate for different countries or regions within a country. These default ring sizes 

17 may be determined experimentally. 

IS There are several distinct advantages associated with the disclosed rank 

19 suppression embodiment. A route calculation program utilizing this rank suppression 

20 feature has the potential to outperform other route calculation programs in quickly 

21 finding routes of high quality, especially for hard problem instances. First, with this 

22 embodiment, a main portion of the search is conducted in a relatively small zone region 

23 of the waypoint of the search tree towards a focus point. This significantly reduces 

24 amount of memory used as well as route calculation time. Second, the present 

25 embodiment allows searching roads of medium or low rank as they appear to be 

26 promising in a poorly connected road network. Thus, the present embodiment is more 

27 likely to finds routes of high quality than prior route calculation programs. In a poorly 

28 connected road network, any route of reasonable quality is required to use some lower 

29 ranked roads. For long range route calculations, prior algorithms may fail to find 

30 quality routes because they search only high ranked roads in the middle of the journey. 

3 1 With the present embodiment, the search for a route can readily use lower layers as 

32 well as higher layers of data, even along a middle portion of a calculated route. 
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2 B. Rerouting . Another feature provided by a present embodiment of the 

3 route calculation tool is an improved rerouting feature. The rerouting feature may be 

4 used when the vehicle in which the navigation system is installed departs from the 

5 originally calculated solution route as the vehicle is traveling. According to one 

6 embodiment of the rerouting feature, after the route calculation tool 40 determines a 

7 solution routed and provides the solution route in a route object 60 to the navigation 

8 application 47, the inbound search tree 1 4 1 (IN) is augmented by adding to it any 

9 portion of the outbound search 141(OUT) tree that formed part of the solution route. 

10 After this step, the now augmented inbound search tree contains the original inbound 

1 1 search tree as well as any gates that were part of the original solution route but which 

12 were in the outbound search tree. This augmented inbound search tree is maintained in 

13 the memory 20 (in Figure 1) of the navigation system 10 or is otherwise stored while 

14 the vehicle is traveling the roads represented by the solution route. 

15 For purposes of this example, it is assumed that the destination has not 

16 changed, but that for some reason, intentionally or otherwise, the vehicle is no longer 

17 traveling on the roads corresponding to the solution route. The rerouting feature of 

18 the route calculation tool 40 is implemented upon detection by the navigation system 

19 that the vehicle is no longer traveling on any of the roads represented by the solution 

20 route (or is no longer traveling in the proper direction on the roads represented by the 

21 solution route). In one embodiment, this detection is made in a map matching program 

22 that is part of the navigation application 18. As the vehicle is traveling, the map 

23 matching program correlates the geographic coordinates derived from the positioning 

24 system 14 (in Figure 1) with the road segment data records in the map database 30. 

25 This may be done for the purpose of providing the end-user with driving instructions in 

26 advance of when a maneuver is required as part of the solution route. This may also 

27 be done on a continuous basis (or at predetermined intervals) for the purpose of 

28 displaying the position of the vehicle on a computer display that is part of the user 

29 interface. As the map matching program determines which segment record in the map 

30 database corresponds to the vehicle position, it compares this segment record to the 

31 list of segment records in the solution route. If the vehicle position corresponds to a 

32 segment record that is not among the records in the solution route (or if the direction 

33 of travel is incorrect), the rerouting feature of the route calculation tool is called. The 
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1 rerouting feature may be implemented as a separate program in the navigation 

2 application 18 or may be implemented as a function or object within the route 

3 calculation tool 40. In a one embodiment, a rerouting function in the navigation 

4 application 47 prompts the end-user to indicate whether he or she wants a new route 

5 (e.g., a re-route) to be calculated. Alternatively, the reroute function can be 

6 implemented automatically without waiting for the end-user to request that rerouting 

7 be performed; 

8 In one embodiment, a navigation position object (e.g. 56 in Figure 4) is 

9 provided that corresponds to the present position of the vehicle. The rerouting feature 
10 may request this information from the geocoding program tool 90 which may be used 

l ] for this purpose. The geocoding tool 90 may obtain the coordinates of the vehicle 

12 position from the map matching program. Alternatively, the geocoding tool 90 may 

13 obtain the position of the vehicle from the navigation application 47 which in turn 

14 obtained the coordinates determined by the positioning system 14. 

15 Once the navigation position object 56 corresponding to the current vehicle 

16 position is obtained, it is provided to the navigation application 47. The navigation 

17 application 47 creates a waypoint object 100 and provides it to the route calculation 

18 tool 40 which is operated in a rerouting mode. According to one embodiment, 

19 operation of the route calculation tool 40 in the rerouting mode is similar to the 

20 operation for normal route searching. An inbound search tree object 140(IN) and an 

21 outbound search tree object 140(OUT) are formed by the route calculation object 50. 

22 The route calculation object 50 uses the waypoint object 100 that represents the 

23 current vehicle position to obtain portal information from which seed gates-108 can be 

24 determined for a new outbound search tree 141(OUT). These new seed gates and 

25 immediate successor gates of these seed gates are determined and added to a new 

26 outbound search tree 141 (OUT) in a new outbound search tree object 140(OUT). As 

27 mentioned above, the inbound search tree 141 (IN) is the augmented inbound search 

28 tree that contains the previously calculated inbound search tree for the original solution 

29 route as well as any gates that were part of the original solution route but which were 

30 in the original outbound search tree 141(OUT). As in a normal search, the gates in 

31 these new inbound and outbound search trees are compared to determine whether the 

32 same gate exists in both the new inbound and outbound search trees. If it does, a 



-45 - 



1 solution route exists and the list of segments that form the solution route is placed in 

2 an output route object 60. 

3 If a solution route was not found in the previous step, the inbound tree 141 (IN) 

4 is grown. The current vehicle position may be used as-the focus 143(IN) of the 

5 inbound search tree 141 (IN). Pointers to all the unexpanded gates in the new inbound 

6 search tree 141 (IN) are stored in a new inbound priority queue object 150(IN), As in 

7 the first described embodiment, any suitable route searching algorithm may be used to 

8 establish a priority among the unexpanded gates in the inbound search tree. When 

9 used for rerouting, the route searching algorithm evaluates each of the positions of the 

10 unexpanded gates relative to the focus 143(IN) which in the rerouting mode 

1 1 corresponds to the current vehicle position. (An alternate priority algorithm may be 

12 used during rerouting to give higher than usual priority to gates that are close to the 

13 new origin. Since the new origin is usually near the old route, this tends to cause the 

14 new route to converge to the old route more quickly.) 

15 The gate in the inbound search tree 141 (IN) with the highest priority as listed 

16 in the inbound priority queue object 1 50(1N) is expanded. As in the normal mode of 

17 operation, the candidate successor gates are examined to determine whether valid 

18 successor gates can be formed. The new successor gates are also examined to 

19 determine whether any of them match a gate in the outbound search tree, and if any 

20 one of them does match, a solution route is found. If there is no match, these valid 

21 successor gates are added to the inbound search tree. The inbound tree continues to 

22 be grown in this manner until a solution route is found. Then, the new solution route 

23 is placed in a new output route object. In a preferred embodiment, only the inbound 

24 tree is grown until a solution is found (i.e., the outbound tree is not searched). 

25 Several advantages are provided by this rerouting feature of the route 

26 calculation tool. If a seed gate (or its successor gates) of the current vehicle position is 

27 already contained in the augmented inbound search tree, then the route to the 

28 destination waypoint is already known and can be identified immediately. Also, if the 

29 seed gate (or its successor gates) for the current vehicle position is not already 

30 contained in the augmented inbound search tree, but the vehicle position is within the 

31 geographic area represented by the gates of the augmented inbound search tree 

32 141 (IN), a solution route to the destination waypoint can be determined very quickly, 

33 because only minimal searching will be required to expand the augmented inbound 
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" 1 search tree to the position of the vehicle represented by a vehicle seed gate (or its 

2 successor gates). 

3 In an alternative embodiment, the original solution route is placed in an input 

4 route object 72. When a previous route is used in this manner, it may be referred to as 

5 a nexus. A nexus is a list of segment records that together form all or part of a route. 

6 A nexus is used to constrain the route searching performed by the route calculation 

7 object 50. When a node of a nexus is encountered while route searching is being 

8 conducted, the nexus is followed from the encountered node to the end of the nexus, 

9 from which further route searching may be performed. Thus, when reroute searching 

10 is performed and a point on the original route (represented by the nexus) is 

1 1 encountered, the rerouting is constrained to follow the remainder of the original 

12 solution route to the destination waypoint. This provides an advantage since a 

13 determination had been made during calculation of the original route that such route 

14 represented the best route according to the chosen parameters. 

15 The rerouting feature provided by a present embodiment of the route 

16 calculation tool 40 provides a significant advantage over prior route searching 

17 programs. In prior programs, searches for rerouting were performed from the vehicle 
IK position to the destination. However, since the vehicle's position is continually 

19 changing as the vehicle moves, rerouting searches required the route calculation 

20 application to predict an origin of the search ahead of the vehicle. The present 

21 embodiment avoids the need to predict an origin ahead of the vehicle because the 

22 rerouting search is performed from the existing inbound tree towards the changing 

23 vehicle position or focus. This calculatioircan be performed relatively quickly because 

24 the vehicle position waypoint (used as the focus of the inbound search tree) represents 

25 a relatively small item of information that changes. The larger amount of information 

26 resides in the inbound search tree, which does not need to be changed. 
27 

28 C. Multiple Solutions . Another feature provided in an alternative 

29 embodiment of the route calculation tool 40 is the provision for multiple searches. 

30 According to this feature, searching can be continued by the route calculation tool 40 

31 after a first solution route is determined thereby creating multiple solution routes. The 

32 route calculation tool 40 then chooses the solution route with the lowest cost. 

33 According to this alternative embodiment, the route calculation tool 40 is configurable 



-47- 



1 so that more than one solution route can be determined and also so that the solution 

2 route delivered to the end-user is chosen according to a user-specified cost function. 

3 In one alternative embodiment, the end-user is then allowed to choose which of the 

4 alternative solutions to accept. 

5 As discussed above, the gates in the priority queues are ordered according to 

6 the highest priority. The priority thus determines the direction in which the respective 

7 search tree grows because, where multiple paths exist, the one leading to the gate with 

8 the highest priority is the one next expanded. One advantage provided according to 

9 this alternative embodiment is that the priority is configurable and may be defined 

10 distinct from the cost of traveling to the gate in question. For example, priority may be 

11 based on the map data in local memory, thereby giving higher priority to node and 

12 segment records which can be read quickly from memory. This may provide a 

n performance advantage over systems where additional map data are required to be 

14 read from the medium on which the map data are stored. 

15 

16 D. Multiple Intermediate Waypoints Another advantageous feature that 

17 may be provided by an alternative embodiment of the route calculation tool 40 is the 

18 determination of routes passing through multiple intermediate waypoints. To provide 

19 for one or more intermediate waypoints, the first intermediate waypoint is treated as a 

20 destination waypoint, and a route is determined between the origin waypoint and the 

21 first intermediate waypoint according to the method described above. Once a solution 

22 route to the first intermediate waypoint is found, the first intermediate waypoint is 

23 treated as the origin waypoint and the second intermediate waypoint is treated as a 

24 destination waypoint. The route searching method described above is again repeated, 

25 and so on, until a solution route is determined between the last intermediate waypoint 

26 and the ultimate destination waypoint. At that stage, the route calculation engine 160 

27 concatenates the routes determined between the various waypoints to provide a single 

28 route from the origin waypoint to the destination waypoint passing through all of the 

29 intermediate waypoints. Customized information about the road network, such as 

30 nexuses and masked segments are retained for each leg of the route calculation. 
31 

32 E. Alternate routes . A further feature provided in an alternative 

33 embodiment of the route calculation tool 40 is the generation of alternate routes. 
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1 These alternate routes can then be reported by the navigation application program 18 

2 to the end-user. 

3 For determining alternate routes, a first solution route is found according to 

4 any of the methods described above. Then, the costs of traversing the road segments 

5 that comprise the first route are increased. Segments having these artificially raised 

6 costs are called "masked segments." The previously described route searching method 

7 is then repeated to calculate a second or alternate route. When gates of the first route 

8 are encountered in the search tree, they will have higher costs than when previously 

9 encountered. These higher costs will be reflected in the priority assigned to each of 

10 these gates in the priority queue. These higher costs reduce the likelihood that any of 

1 1 the gates from the original solution route will be selected thus helping to ensure that an 

12 alternate route will be found with only minimal overlap between the original and 

13 alternate routes. Once a second route is determined, its segments may be masked and 

14 the procedure may be repeated to determine yet another additional alternate routes, 

15 and so on. 

16 The provision for alternate routes has an advantage that alternate routes can be 

17 determined without altering the optimization criteria. This means that the alternate 

18 route can still be optimized for the same criteria (e.g., time, distance, etc.), but still 

19 represent another route to the destination. 
20 

21 F. Progress callback feature. Another advantage provided by an 

22 embodiment of the route calculation tool is a progress callback feature. The progress 

23 callback feature allows the navigation application 47 to interrupt the route calculation 

24 function when it appears to be taking too long or when the navigation application 47 

25 needs the allocated memory or processor for other higher priority functions. In 

26 providing this feature, an embodiment of the route calculation tool 40 provides 

27 information to the navigation application program at defined intervals. For example, 

28 the route calculation tool 40 may provide information each time a gate is expanded, or 

29 after every ten gates have been expanded, and so on. This permits the navigation 

30 application 47 to interrupt the route calculation tool 40, as needed, but also allows the 

31 navigation application 47 to provide a partial solution route which can be used for 

32 various purposes, such as map display. 
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2 G. Real time traffic weighting An embodiment of the route calculation 

3 tool 40 also provides a mechanism for the navigation application 47 to incorporate real 

4 time traffic information in the route calculation determination. The route calculation 

5 tool 40 may provide for accepting input about the cost of traversing a segment taking 

6 into account traffic conditions. For example, the cost of a segment may be increased 

7 due to rush hour traffic or an inhibiting traffic incident. This information may be 

8 provided to the navigation system by wireless transmission from a traffic monitoring 

9 service. The route calculation object 50 can check and account for such traffic 
10 information as each gate is expanded in a search tree. 

LI 

12 H. Use o f nexus routes As mentioned above, a route object can be used 

13 as an input ("72" in Figure 4) to the route calculation object 50. When used in this 

14 manner, the previous route is incorporated as part of a new route being calculated. 

15 When a previous route is used in this manner, it is referred to as a nexus, as mentioned 

16 above. A nexus is used to constrain the route searching performed by the route 

17 calculation object. When any location along a route represented by a nexus is 

18 encountered while route searching is being conducted, the nexus is followed from the 

19 point of encounter to the destination end of the nexus. Further route searching may be 

20 performed from the destination end of the nexus. A route object used as a nexus 

21 includes an entire route and may have a format identical to the route object. The route 

22 object used as a nexus may be a route object previously calculated by the route 

23 calculation tool or may be provided by another source. — — 

24 There are a number of uses for nexus routes. These uses include providing a 

25 previously determined preferred route. The previously determined preferred route may 

26 be a user-configurable preferred route, or alternatively may be determined to be 

27 preferred by the navigation application or the provider of the geographic database. 

28 Another use for a nexus route includes re-routing. The original route can be 

29 used as a nexus. When performing re-routing using a nexus, the new re-routing route 

30 is calculated to the original route, not to the original destination. When the re-routing 

31 route encounters the original route, the original route is followed to its destination 

32 Nexus routes may also be used for long, predefined routes, such as routes 

33 between cities. These predefined routes may be stored in the geographic database 30. 
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1 Another use for nexus routes is scenic routes. These scenic routes may also be 

2 predefined and stored in the geographic database. 

3 

4 /. Multiple origins and destinations. Another feature provided by the 

5 disclosed embodiments of the route calculation tool is that they readily accommodate 

6 finding solution routes that have multiple origins, multiple destinations, or both 

7 multiple origins and destinations. As mentioned above, when the route calculation 

8 object 50 forms the inbound and outbound search tree pair to be used for determining 

9 a solution route for a leg of an overall route, it starts by adding one or more seed gates 

10 to each search tree. Each of these seed gates represents an initial means of access out 

1 1 of (or into) one of the portals of its respective waypoint. The route calculation tool is 

12 not limited to using only one waypoint in each search tree. Multiple waypoints can be 

13 used with each search tree. When using multiple waypoints in a single search tree, 

14 seed gates are formed for each portal of each waypoint and all these seed gates added 

15 to the single search tree. Then, the route calculation object operates as described 

16 above to determine a solution route between the waypoints. 

17 Using the route calculation tool to find a solution route between multiple origin 

18 waypoints and/or multiple destination waypoints can be applied to a variety of 

19 situations. For example, a delivery service may have several vehicles at different 

20 locations that can be called to make a pickup at a particular place. A navigation 

21 system incorporating the route calculation tool 40 may be located at a central 

22 dispatching facility. Origin waypoint objects are formed to represent the locations of 

23 each of the vehicles and a destination waypoint object is formed to represent the place 

24 of pickup. These multiple waypoints objects are provided to the route calculation 

25 object in the route calculation tool. The route calculation object forms seed gates for 

26 each of these multiple origin waypoint objects. The seed gates formed from the portals 

27 of the multiple waypoint objects that represent the vehicle positions are added to a 

28 single outbound search tree. The seed gates formed from the portals of the waypoint 

29 object that represents the pickup location are added to the inbound search tree. 

30 A solution route is determined, as described above. When the routing 

3 1 algorithm is applied to determine which gates to expand, the gates of the multiple 

32 origins are automatically weighed against each other. A solution route is found that 

33 minimizes cost, regardless of the number of origin locations. 
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1 Multiple origin waypoints and/or multiple destination waypoints can also be 

2 used to find the lowest cost route to any of a variety of destinations. For example, if 

3 an end-user wants to visit any one of four restaurants, each of these restaurants can be 

4 represented by a destination waypoint. Four destination waypoint objects are formed 

5 and seed gates for each are added to an inbound search tree. The route calculation 

6 tool is operated and a solution route of minimum cost is found to one of the 

7 restaurants. 
8 

9 TV. ADVANTAGES OF THE DISCLOSED EMBODIMENTS 

10 An advantage provided by the disclosed embodiments is derived from the use 

11 of a waypoint to represent a location, such as the origin, the destination, and any 

12 intermediate stops. Waypoints are used to calculate routes with more precision and 

13 more consistently than was possible with prior systems. As mentioned above, the map 

14 database 30 contains node data records and segment data records. The node data 

15 records represent positions at the ends of road segments and include data identifying 

16 the geographical coordinates (latitude and longitude) of these positions. Segment data 

17 records represent portions of roadways between positions represented by node data 

18 records . A waypoint (which can represent an origin, a destination, or an intermediate 

19 location along a route) is not necessarily located at an end of a road segment, but 

20 instead may be located anywhere in the geographic region, including along portions of 

21 roadways between intersections. Since a portion of the roadway located between 

22 nodes is represented by a segment data entity, the physical location represented by a 

23 waypoint is associated with a position along-aportion of a roadway represented by a 

24 segment data record in the map database 30. One benefit that results from the use of 

25 waypoints is that a means is provided to provide route calculation and guidance to 

26 locations between nodes (e.g., along segments), and more particularly, precisely to the 

27 entrance and exits of points of interest and other locations.. 

28 Using the gates allows the route calculation tool 40 to define both a position 

29 and a direction. By contrast, in prior systems that used only nodes and edges, it was 

30 necessary to create multiple additional nodes at an intersection to define a direction 

31 with attributes or conditions, such as turn restrictions, to accurately define the 

32 permissible routes of travel. In a present embodiment, a gate defines a node and a 

33 direction from that node towards the node at the other end of the segment, thereby 
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1 linking the two nodes by a defined path. The gate may also include a segment 

2 identifier (e.g., "ID") that uniquely identifies the path between the two nodes. 

3 Another of the advantages provided by the route calculation tool is that it is 

4 able to provide instructions at a finer level of detail than previous navigation programs. 

5 Still another advantage provided by an embodiment of the navigation tool is 

6 that it is preferably an object oriented application. Using an object oriented approach, 

7 the route calculation program can be adapted for use in various different kinds of 

8 navigation systems with little or no modification. 

9 Present embodiments provide a concise data model used for searching optimum 

10 routes in a complex road network. This data model includes search trees and data 

1 1 structures such as gates, waypoints, and portals. These structures enable the 

12 navigation application to provide detailed instructions to an end-user in a road network 

13 with various constraints such as irregular start and end locations. Conventional 

14 approaches (e.g., graph theory applications) would require data models of much larger 

15 size in these types of road networks. 

16 Present embodiments also provide a new road search suppression heuristic 

17 developed for speeding up the search, especially for long range route searches. Low 

18 rank roads are quickly eliminated from consideration except in a generic ring shaped 

19 region relative to a specified focus point (e.g., the origin, the destination, or an 

20 intermediate waypoint). The size of the main search region is relatively small, 

21 depending on the road structure and the search position. Moreover, this generic 

22 search region is configurable with a set of tunable parameters for further performance 

23 improvement. The search heuristic significantly reduces route calculation time and 

24 memory usage while it finds routes of high quality. 
25 

26 It is intended that the foregoing detailed description be regarded as illustrative 

27 rather than limiting and that it is understood that the following claims including all 

28 equivalents are intended to define the scope of the invention. 
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